Replacing Semaphores with Mesa Monitors
John M McIntosh
johnmci at smalltalkconsulting.com
Fri May 14 03:09:34 UTC 2004
On May 13, 2004, at 3:35 PM, Andrew P. Black wrote:
> I'm aware that this is a dangerous area to mess with - which is why I
> was hoping not to. But I don't really understand these comments. Is
> there a document that describes threading in the VM in more detail?
Er, not really.
It's safe to assume the OS or plugin or something will do an async call
to signal a semaphore. This can occur on a process/thread outside the
process/thread running the interpreter.
>
> My naïve thinking was that Squeak runs in a single OS thread, and
> therefore there is no real concurrency, and that the interpreter main
> loop was never preempted. There are signals from the OS, however,
> indicating things like data on a socket. I imagined that these got
> queued up somehow, and that the interpreter main loop would check the
> queue each cycle. Alternatively, I suppose it would be possible to
> let the OS signal handlers directly execute the semaphore primitives,
> but then one would have to do really hairy stuff to make sure that the
> semaphore primitives were not made non-atomic with respect to the
> signal handler executions. Is this the problem that you are referring
> to?
>
> Andrew
I'm not sure it needs to be hairy you should look at what it does now
and see how it maps to what you
want to do.
--
========================================================================
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
========================================================================
===
More information about the Squeak-dev
mailing list
|