pthreads in squeak (was: OSProcessPlugin loads incorrectly in
bert at freudenbergs.de
Thu Nov 23 18:08:27 UTC 2006
Thanks for the pointers - you pushed me into the right direction.
Turns out ALSA does not restore the VM's SIGIO handler but sets it to
I implemented a workaround which seems to work (attached).
- Bert -
On Nov 19, 2006, at 19:38 , David T. Lewis wrote:
> Excuse me for following up on my own reply, but it occurs to me that
> a much easier way to figure out what is happening to the SIGIO handler
> is to just set a gdb breakpoint on the signal() call. Do this right
> before you re-enable the sound via the async command, and you will
> probably break on some plugin trying to restore the signal handler
> to its default value (which would be incorrect).
> On Sun, Nov 19, 2006 at 10:10:24AM -0500, David T. Lewis wrote:
>> On Sat, Nov 18, 2006 at 10:49:05PM +0100, Bert Freudenberg wrote:
>>> On Nov 18, 2006, at 21:18 , David T. Lewis wrote:
>>>> Right, in Squeak a Process is like a "green thread". However, the
>>>> VM may choose to use threads for its own purposes, and specific
>>>> plugins may
>>>> do so also even if the VM is single threaded.
>>> I'm currently puzzled by a thread / signal related problem on OLPC.
>>> Ian recently added an ALSA sound module which we use. Also, I'm
>>> AsyncFile for reading commands from a pipe. Commands that I send
>>> include disabling/enabling of sound. Now, the problem is, as soon as
>>> I re-enable the sound via an async command, the VM is terminated
>>> by a
>>> SIGIO. I suspect it related to ALSA which forks off a thread,
>>> in the main VM we actually have a handler for SIGIO. Ian thinks it
>>> might have to do with the AsyncFile plugin. Unfortunately, I have no
>>> idea how to debug this ... do you?
>> Hi Bert,
>> I don't see how it could be the AsyncFilePlugin, because that
>> plugin does
>> not manipulate any signal handlers. And assuming that the VM is
>> cleanly (as opposed to a seg fault), then the problem is not
>> likely to be
>> caused by pthread signal delivery, although this could also be a
>> A plausible scenario might be:
>> - VM sets its signal handler for SIGIO.
>> - Some plugin sets the SIGIO handler for its own purposes, but
>> does not
>> bother to remember the prior signal handler setting.
>> - The plugin decides that it is done, and restores the SIGIO
>> handler to
>> its default value instead of restoring the handler to the one
>> that the
>> VM wants to use.
>> - The next SIGIO that arrives goes to the default handler, which
>> the VM.
>> I am attaching a change set that may help narrow the problem down.
>> can use it to list the values of signal handlers, and you can also
>> set your
>> own signal handler that forwards SIGIO to a semaphore in the image,
>> overriding any handler that was previously set by either the VM or a
>> plugin. For example, in a workspace:
>> --- workspace example --
>> "List all current signal hander addresses to Transcript or to Unix
>> OSProcess accessor listSigHandlerAddressesOnConsole.
>> OSProcess accessor listSigHandlerAddressesOnTranscript.
>> sigIoNum := 29. "check to see that this matches your Linux system"
>> OSProcess debugMessage: 'SIGIO is ', sigIoNum printString.
>> "Figure out the current C pointer address of the SIGIO handler"
>> previousHandlerAddress := OSProcess accessor
>> currentSigHandlerAddress: sigIoNum.
>> OSProcess debugMessage: 'SIGIO hander is ', previousHandlerAddress
>> "Forward SIGIO to the image to prevent the VM from exiting"
>> sema := OSProcess accessor forwardSignal: sigIoNum.
>> sema inspect. "watch excessSignals in the semaphore"
>> "Now you can do 'kill -29 <squeakpid>' from Unix command line, and
>> the excessSignals will increment in the semaphore."
>> "Revert to prior signal handler, and undo signal forwarding"
>> unregisteredSema := OSProcess accessor restoreSignal: sigIoNum.
>> --- end workspace example ---
>> You'll need OSProcess and an OSProcessPlugin, which I assume you can
>> add for purposes of debugging. If you build an OSPP from source, I
>> suggest using the latest from SqueakSource (not released), which is
>> Before building, edit platforms/unix/plugins/UnixOSProcessPlugin/
>> to contain these two lines:
>> AC_CHECK_FUNC(unsetenv, AC_DEFINE(HAVE_UNSETENV, 1))
>> AC_PLUGIN_CHECK_LIB(pthread, pthread_kill)
>> Then do 'cd platforms/unix/config; make' to update the configure
>> script before
>> doing the build. While you're at it, if you can ask Ian to check
>> the acinclude.m4
>> change into Subversion, that would be helpful.
>> I'd be happy to try some debugging on my end if you think it might
>> although my Linux system is rather old:
>> Linux version 2.4.21-303-default (root at i386.suse.de) (gcc version
>> 3.3.1 (SuSE Linux)) #1 Tue Dec 6 12:33:58 UTC 2005
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 800 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20061123/4072e1ff/ALSA.diff.bin
-------------- next part --------------
More information about the Squeak-dev