Skip to main content

Execution Model

Lifecycle

Weaver's execution model is simple yet orderly, ensuring all controllers and services will be ready as soon as their respective hosts start Weaver.

  1. Weaver is required
  2. WeaverServices and WeaverControllers are created
  3. WeaverServer.Start() and WeaverClient.Start() respectively are called
    1. Weaver internally constructs the services when WeaverServer.Start() is called
  4. Every WeaverInit method is invoked
    1. Weaver waits for all respective WeaverService:WeaverInit() and WeaverController:WeaverInit() methods to resolve before continuing to the next step
  5. Every WeaverStart method is invoked, spawning new threads for all services and controllers
  6. All threads yielding from WeaverServer.OnStart() and WeaverClient.OnStart() respectfully are resumed

Weaver's Execution Model

Explanation

When WeaverServer.Start() is called, all of the WeaverServices are instantiated internally, which includes RemoteSignals and methods. This step does not happen on the client, rather, services are dynamically created when WeaverClient.GetService() is called.

Internally, all services' signals and their attributes are guaranteed to be ready when they are returned using WeaverClient.GetService(). This is because they are created before WeaverInit, as other services may use or rely on a service's RemoteSignals during WeaverInit or WeaverStart. This is the same for how WeaverControllers behave, just without creating instances.

caution

WeaverServices and WeaverControllers are unable to be created once their respective hosts have started Weaver.

Best Practice

When using Weaver, your project structure should generally follow these rules:

Since Weaver relies on a single-script architecture, it may not work correctly if your project has a multi-script architecture.