All -
Since I'm new here, I'm not sure if this has been discussed, so please bear with me.
I've been giving some thought to the external primitive mechanism and was wondering if any thought had been given to somehow integrating some of the primitive support with the Smalltalk process model and native OS threading. At the moment, calling an external primitive occurs in the same native thread as the rest of VM, which means everything grinds to a halt until the primitive is complete. The question is this - is it possible to add another parameter to the <primitive> call which tells the VM to attempt to run the (thread-safe) primitive in another native thread, and suspend the current Smalltalk Process, then resume it when the primitive completes.
An alternative is to provide VM callbacks that allow the plug-in developer to initiate that behavior in sections that aren't otherwise requiring support of the VM.
I expect there will be at some point be primitives that are time-consuming for some reason, but aren't critical enough to wait for. An example might be some sort of compression or encryption which might be difficult to factor for a polling model.
=================================================== Duane Maxwell dmaxwell (at) launchpados.com CTO http://www.launchpados.com Launchpad, Inc. (619) 578-8500 x226
Information contained herein is my personal opinion and not necessarily that of Launchpad, Inc. ===================================================
At the moment, calling an external primitive occurs in the same native thread as the rest of VM, which means everything grinds to a halt until the primitive is complete.
It is not required that a primitive does it's work in the same OS thread that is executing Smalltalk. I believe there are primitives used by Squeak already that use a separate OS thread to accomplish their work. I think the file i/o primitives on the Macintosh work this way. And the network I/O primitives used by NetCorrespondent are also asynchronous.
The question is this - is it possible to add another parameter to the <primitive> call which tells the VM to attempt to run the (thread-safe) primitive in another native thread, and suspend the current Smalltalk Process, then resume it when the primitive completes.
Yes, but this is not the way one would normally accomplish this. Instead async 'read' primitives would be given a Semaphore to signal when they have the data requested. Then the 'read' primitive could fork a separate OS thread to accomplish the work and the primitive would return immediately. When the forked thread finishes it would signal the Semaphore. Then Smalltalk would call a second primitive to get the data from the VM.
This allows other Processes in Smalltalk to run while an asynchronous primitive runs.
squeak-dev@lists.squeakfoundation.org
-
Carl Gable Watts -
Duane Maxwell