Eventloop thread will spin forever? about clearscriptworkersample HOT 3 OPEN

Hi @nextfool,

Does this mean that, without an exit signal(a call to PostExit or an exception in any of the event handlers), this message loop will spin forever, even the message queue is empty, and the main script has finished execution?

Well, yes and no. The message loop's asynchronous operation will remain active. It's a loop after all, and unless terminated it'll continue to... loop. However, it doesn't "spin", in the traditional sense of that term, because, unless it's processing a message that ties up a thread, it consumes no resources beyond the memory required to hold the Task instance.

Note that the main program awaits message loop termination via WaitForExitAsync. If you remove that call, the program exits immediately. The message loop doesn't prevent it.

Further more, since the loop is started with Task.Run, does it mean that a thread from thread pool is long running and not going to be released?

No. The loop implementation is 100% asynchronous. When invoked, MessageLoop immediately reaches an await, at which point it releases the thread. A message handler can subsequently block a thread, but the loop itself does not.

Cheers!

from clearscriptworkersample.

Hi @ClearScriptLib ,

No. The loop implementation is 100% asynchronous. When invoked, MessageLoop immediately reaches an await, at which point it releases the thread. A message handler can subsequently block a thread, but the loop itself does not.

Does this mean that, the MessageLoop does not work the same as the "event loop" in a browser or Node.js? In those cases, the loop handles the events synchronously, and it will block if one of the event handler takes long time to run.

If I invoke the message handlers synchronously, the loop will "spin" for real then?

from clearscriptworkersample.

Hi @nextfool,

Does this mean that, the MessageLoop does not work the same as the "event loop" in a browser or Node.js?

Our understanding is that, in a browser, the main event loop handles all events on the same thread, which is important in that environment because of script code's potential interaction with the UI/DOM. We can't say whether Web Workers or Node.js work the same way. The distinction shouldn't affect script code.

In those cases, the loop handles the events synchronously, and it will block if one of the event handler takes long time to run.

The loop implementation has no control over what an event handler might do. It could issue a blocking I/O call, or perform a long calculation, and that's perfectly fine. An asynchronous loop implementation, such as the one we have here, certainly allows that, but it also supports asynchronous event handlers. Either way, the loop will only allow one event handler to run at a time.

One thing this implementation doesn't do is provide a way for event handlers to overlap their asynchronous operations using the loop to interleave script execution. That approach is a requirement in native hosts such as browsers and Node.js, whereas .NET hosts can use the thread pool in conjunction with script engine locks to achieve similar results. Still, support for that might make this implementation more useful, so we'll look into it.

Cheers!

UPDATE: OK, we've looked into it, and it seems quite easy to do. We'd just need a custom implementation of SynchronizationContext that posts items to a worker's queue.

from clearscriptworkersample.