spair at advantive.com
Mon Jun 18 18:11:19 UTC 2001
You might be able to create something like a "HostThread" class that when
instantiated would maintain a handle to a platform independent structure
that would in turn hold a reference to the platform dependent handle (much
like the Socket code works). You would then have a set of primitives
appropriate for host threads. There would always be one of these threads in
which the image runs. Then, you could at least use Smalltalk code to create
and maintain the host thread pools.
The FFI code could be made a little more generic such that calls could be
dispatched on any available thread...and if it happened to be the Smalltalk
thread, the behavior would be identical to the current situation.
If the VM for a particular plaform didn't support host threads for foreign
calls, then the FFI framework would only have one thread (the one the
Smalltalk code uses) from which to choose.
> -----Original Message-----
> From: Tim Rowledge [mailto:tim at sumeru.stanford.edu]
> Sent: Monday, June 18, 2001 1:19 PM
> To: squeak at cs.uiuc.edu
> Subject: Re: multi-threaded squeak
> > It would be great to have this for FFI, and it's not
> particularly difficult
> > to implement. I don't know if there is any explicit support
> for doing this
> > for Plugin primitives, but I suspect not. Am I right about that?
> The nearest I can think of right now is the usage of the
> AsynchFilePlugin and the asynch parts of the Socket code. There's
> nothing in the plugin per se, but it isn't hard to include a semaphore
> in the API and make you platform code use a suitable thread to signal
> that sem when appropriate.
> I've not yet heard of a truly portable OS thread system, so I'd strongly
> recommend that you never include the thread stuff in the plugin code but
> leave it in the platform code.
More information about the Squeak-dev