ithreads + signals on modern Unices

[Thomas Jahns]

I wish to make a background application I told to 'use threads;' also
react nicely to a SIGHUP (and reread configuration). perldoc perlthrtut
tells me not to mix signals and ithreads but the other aspects to
consider are as follows:

- I don't care for portability to Win32, pre-X MacOS, MVS or whatever
platforms may also provide a Perl implementation. I just need the
program to run on relatively modern Unices (i.e. pthreads and POSIX
sigaction will be available).

- perlthrtut also tells me 'use Thread;' will break real soon and isn't
so great to begin with, and Thread::Queue which my program already
uses is--surprise--not meant to work with Thread but threads anyway.

So I seek a description of signal semantics for the systems outlined
when using ithreads. Is there such documentation available? I searched
but apart from the Perl source couldn't find anything useful (not that I
didn't get many google hits, but what I got was either outdated or a
repetition of the message from perlthrtut).

Since the I really like the ease at which Perl allows me to write
programs for Unix/Linux I'd really hate to turn my program into ten
times the number of code lines of C.

Thomas Jahns

 

[Thomas Jahns]

I wish to make a background application I told to 'use threads;' also
react nicely to a SIGHUP (and reread configuration). perldoc perlthrtut
tells me not to mix signals and ithreads but the other aspects to
consider are as follows:

- I don't care for portability to Win32, pre-X MacOS, MVS or whatever
platforms may also provide a Perl implementation. I just need the
program to run on relatively modern Unices (i.e. pthreads and POSIX
sigaction will be available).

- perlthrtut also tells me 'use Thread;' will break real soon and isn't
so great to begin with, and Thread::Queue which my program already
uses is--surprise--not meant to work with Thread but threads anyway.

So I seek a description of signal semantics for the systems outlined
when using ithreads. Is there such documentation available? I searched
but apart from the Perl source couldn't find anything useful (not that I
didn't get many google hits, but what I got was either outdated or a
repetition of the message from perlthrtut).

Since the I really like the ease at which Perl allows me to write
programs for Unix/Linux I'd really hate to turn my program into ten
times the number of code lines of C.

So does the lack of answers mean, that I

- I did not describe my intended application clearly enough?
- I should take this question to a Unix programming group?
- I violated etiquette really badly?
- noone except me cares about using threads and still handling
signals, after all it has to work every time one calls system(), or
not?

Please, any pointer will do, even if it means I'll have to either dig
through the Perl or rather rewrite in C.

Thanks for any input,
Thomas Jahns

 

[brianr]

So does the lack of answers mean, that I

- I did not describe my intended application clearly enough?
- I should take this question to a Unix programming group?
- I violated etiquette really badly?
- noone except me cares about using threads and still handling
signals, after all it has to work every time one calls system(), or
not?

Please, any pointer will do, even if it means I'll have to either dig
through the Perl or rather rewrite in C.

If it is any of those reasons, it is likely to be the last, as I would
expect (hope?) that not many people want to combine signals and
threads. It is generally considered to be a bad idea. David Butenhof
in his book "Programming with POSIX Threads" gives a good explanation
of why.

If you do have to use threads and signals together the usual advice is
to use signal masks to block signals from all threads, and collect
signals in a dedicated thread which blocks on one of the sigwait
variants. Unfortunately, I believe that this is part of the POSIX API
that Perl doesn't provide (as mentioned in perlthrtut).

I would recommend finding a different way of doing what you want.

HTH

 

[Thomas Jahns]

If it is any of those reasons, it is likely to be the last, as I would
expect (hope?) that not many people want to combine signals and
threads. It is generally considered to be a bad idea. David Butenhof
in his book "Programming with POSIX Threads" gives a good explanation
of why.

If you refer to pages 215 ("It is always best to avoid using signals in
conjunction with threads.") he does also state just in the next sentence
why avoiding is also not the only solution.

If you do have to use threads and signals together the usual advice is
to use signal masks to block signals from all threads, and collect
signals in a dedicated thread which blocks on one of the sigwait
variants. Unfortunately, I believe that this is part of the POSIX API
that Perl doesn't provide (as mentioned in perlthrtut).

Which is really annoying, because I really can't see why not make
pthread_sigmask available. I think I'll try to find out how perl
implements ithreads and if I can pry the necessary information from the
threads module to make the additional C functions useful.

I would recommend finding a different way of doing what you want.

As it seems, I don't have any easy way to do this. One of the threads is
blocked in a recv (which AFAIK is actually libc's recvfrom) and on
certain conditions I need to wake it, immediately.

Thomas Jahns

 

[brianr]

As it seems, I don't have any easy way to do this. One of the threads is
blocked in a recv (which AFAIK is actually libc's recvfrom) and on
certain conditions I need to wake it, immediately.

How about blocking on select rather than recv. Your file descriptor
set would include a pipe (for example) that you could use to unblock
the thread in the event of "certain conditions".

HTH