[Vm-dev] VM Semaphores and external native threads

John McIntosh johnmci at smalltalkconsulting.com
Thu Nov 9 03:01:07 UTC 2017


In the past the semaphore signaling logic was written to be mostly thread safe because I was driving it from a UI thread and we had to queue requests as the VM only processed the queue every N ms. Don’t know where it sits today as it was rewritten. 

Sent from my iPhone

> On Nov 8, 2017, at 18:32, David T. Lewis <lewis at mail.msen.com> wrote:
> 
> 
>> On Wed, Nov 08, 2017 at 10:56:50PM -0300, Ronie Salgado wrote:
>> 
>> Hi,
>> 
>> I started to make an IDE like tool in Pharo, and I have an external library
>> for handling some asynchronous events generated in a separate thread, which
>> I am putting in a queue that I am polling each 200 ms from a Pharo image.
>> Currently I am using this library for handling pipes of external process
>> (GDB with the machine interface), and next I am going to add support for
>> inotify.
>> 
>> I know that I can remove this polling each 200 ms by implementing a
>> mechanism for registering multiples event handlers that are called by
>> ioProcessEvents. The SDL2DisplayPlugin registers an event handler in this
>> places, which asks SDL2 for the presence of events and it signals VM
>> Semaphore. However, since in this case I have control of the code in the
>> external thread, I would like to just signal the VM Semaphore in this
>> external thread to avoid this polling. So here is my question:
>> 
>> Is signaling a VM Semaphore thread safe? In case it is not, how much work
>> would require to make it thread safe.
>> 
>> Best regards,
>> Ronie
> 
> Do you mean #signalSemaphoreWithWindex: which signals a Smalltalk semaphore
> from the VM or plugin? My expectation is that this is intended to be called
> from the main interpreter thread, and would not be thread safe with respect
> to calling it from other threads running in the VM. I expect that you would
> need to synchronize access to signalSemaphoreWithIndex: in order to make this
> work.
> 
> Dave
> 


More information about the Vm-dev mailing list