Squeak VM, real-time I/O, and threading

Noel J. Bergman noel at devtech.com
Fri Jan 25 22:33:18 UTC 2002


Andreas Raab:
> > > The real problem is latency of Squeak itself. E.g.,
> > > when we use the sound player it's the main thread
> > > of Squeak that does a lot of the work (namely waiting
> > > for a buffer tobecome free, calling the sound
> > > generation prims, and submitting a new buffer).

Noel:
> > Which is why I asked about creating a separate thread to
> > handle all of that.  As long as so much effort is being
> > put into refactoring and improving various parts of
> > Squeak, why not get multi-threading into it, so that such
> > real-time activities are not on the main thread?  I do see
> > some multithreading in the Win32 support code, but not much.

Andreas Raab:
> so you're talking about attaching a native thread to a Squeak
> process, are you?! Interesting idea. I have no idea about the
> synchronization issues in the VM [...]

As far as I can see, there are some native threads created in some of the
I/O native code.  There are a total of 9 calls to CreateThread in the Win32
VM, a few of which are tied to DirectSound.  Tracing the code, it appears
that there is a new PlayerProcess started in Squeak, which is the code
responsible for feeding data to the playbuffer managed by the separate
thread.  Is that a correct reading of the code?

I guess the issue is how best to integrate such threads with the Smalltalk
code that cares about the I/O.  Perhaps Craig has some ideas regarding Flow,
or someone else has some ideas about multithreading the interpreter so
Smalltalk processes could be run on real threads (when available).

I guess it's time to return this thread (no pun intended) back to the main
list.

	--- Noel




More information about the Squeak-dev mailing list