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.
===================================================