Although SCOOP brings simplified concurrency to the table, there may be some circumstances where the use of the EiffelThread library is needed.
Here a locally typed worker_thread object is instantiated from a scoop processor and passed an agent that is created from the processor itself. When the thread goes to launch and execute the worker agent, the thread calls the agent as if it was created by the thread. This can lead to problems in the case where the routine represented by the agent has calls on separate objects. Previous versions of the SCOOP run-time would treat all objects created from a processor as always separate to a thread and therefore leading to issues further down the line as only SCOOP processors can handle separate calls. In order to solve/workaround this, an EiffelThread has to be thought of solely as a worker thread for the SCOOP processor that creates the initial thread object (`worker_thread' in the example), so any calls on objects created from the parent processor are treated as local.
Currently the run-time has been updated to handle local calls on parent processor owned objects, but as of writing there is no restriction on logging calls on separate types from an Eiffel Thread but a run-time check will be generated in the future.