Question 1:
Explain something to me. I am building a webapp and creating a background worker than Initializes a Class as variable in this worker. The worker has a sub that returns the instance of this class. If from a handler I declare a same type class, and request from the worker the class instance to set it to this same type class in the handler, then if I call a method with callsubdelayed in the handler in which thread does the code execute? in handler's thread or in worker's thread? Go through B4X forums if you do not know the answer.
Answer:
Short answer: **it executes in the worker’s thread**, assuming the class instance was created/initialized inside the background worker and that worker called `StartMessageLoop`.
Your handler variable does **not** create a new object just because it is declared as the same type. It only holds a **reference** to the same instance that lives in the worker.
So conceptually:
```b4x
'In handler
Dim x As MyClass = Worker.GetInstance
CallSubDelayed(x, "DoSomething")
```
`x` points to the worker-created `MyClass` instance. `CallSubDelayed` posts the call to that instance’s message queue. Since that instance was initialized from the background worker thread, the delayed sub should run on the **worker thread**, not the handler request thread.
The important distinction:
```b4x
x.DoSomething
```
runs immediately on the **current handler thread**.
But:
```b4x
CallSubDelayed(x, "DoSomething")
```
is queued and later executed by the **target object’s message loop**, which in your case is the background worker’s loop.
This matches the B4J docs: `AddBackgroundWorker` creates and initializes the class from a background thread, and `StartMessageLoop` keeps that worker instance running there. `CallSubDelayed` calls the sub after current execution completes, via the message queue. The server docs also note that handlers may run in different threads unless `SingleThreadHandler=True`, so direct calls from handlers are not automatically on the worker thread.
Sources:
[B4J jServer docs: AddBackgroundWorker / handlers / thread index](https://www.b4x.com/b4j/help/jserver.html)
[B4J Core docs: CallSubDelayed and StartMessageLoop](https://www.b4x.com/b4j/help/core.html)
Practical rule: **direct method call = caller’s thread; `CallSubDelayed(targetInstance, ...)` = target instance’s m-loop thread.**
Question 2:
So if two handlers are called in the same time and they are both implementing the same behavior (getting class instance from worker - "Dim x As MyClass = Worker.GetMyClass") and they both execute x.DoSomething at the same time, then describe how is this executed (like two different subs on each handler's thread?).
Answer:
Yes. If both handlers do:
```b4x
Dim x As MyClass = Worker.GetMyClass
x.DoSomething
```
then they are both holding a reference to the **same `MyClass` instance**, but `DoSomething` is executed **directly on each handler’s current request thread**.
So if two requests arrive at the same time:
```text
Request A -> Handler instance/thread A -> x.DoSomething
Request B -> Handler instance/thread B -> x.DoSomething
```
Both calls can run **concurrently** against the same object.
That means it is not like “the class belongs to the worker, so its methods always run in the worker.” The object was created in the worker, but a direct method call runs wherever you call it from.
So this:
```b4x
x.DoSomething
```
means:
```text
Run DoSomething now, on my current thread.
```
While this:
```b4x
CallSubDelayed(x, "DoSomething")
```
means:
```text
Post DoSomething to x's message queue, so it runs later on x's m-loop thread.
```
Therefore with two simultaneous handlers:
```b4x
'Handler A
Dim x As MyClass = Worker.GetMyClass
x.DoSomething
```
```b4x
'Handler B
Dim x As MyClass = Worker.GetMyClass
x.DoSomething
```
you effectively get:
```text
Handler thread A enters MyClass.DoSomething
Handler thread B enters MyClass.DoSomething
Both may be inside the same method at the same time
Both operate on the same instance fields
```
So if `DoSomething` reads/writes shared state inside `MyClass`, you need to protect it: use `CallSubDelayed` to serialize the work through the worker’s message loop, or use locks/thread-safe structures if direct concurrent access is intentional.
In a webapp, I’d usually prefer this shape:
```b4x
CallSubDelayed2(x, "DoSomething", RequestData)
```
so the worker-owned object stays worker-owned in practice, not just in where it was created.