ithreads + signals on modern Unices

Discussion in 'Perl Misc' started by Thomas Jahns, Feb 7, 2005.

  1. Thomas Jahns

    Thomas Jahns Guest

    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
    --
    "Computers are good at following instructions,
    but not at reading your mind."
    D. E. Knuth, The TeXbook, Addison-Wesley 1984, 1986, 1996, p. 9
     
    Thomas Jahns, Feb 7, 2005
    #1
    1. Advertising

  2. Thomas Jahns

    Thomas Jahns Guest

    Thomas Jahns <> writes:
    > 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
    --
    "Computers are good at following instructions,
    but not at reading your mind."
    D. E. Knuth, The TeXbook, Addison-Wesley 1984, 1986, 1996, p. 9
     
    Thomas Jahns, Feb 17, 2005
    #2
    1. Advertising

  3. Thomas Jahns

    Guest

    Thomas Jahns <> writes:

    > Thomas Jahns <> writes:
    >> 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.


    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

    --
    Brian Raven

    I don't like this official/unofficial distinction. It sound, er, officious.
    -- Larry Wall in <>
     
    , Feb 18, 2005
    #3
  4. Thomas Jahns

    Thomas Jahns Guest

    writes:
    > 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
    --
    "Computers are good at following instructions,
    but not at reading your mind."
    D. E. Knuth, The TeXbook, Addison-Wesley 1984, 1986, 1996, p. 9
     
    Thomas Jahns, Feb 20, 2005
    #4
  5. Thomas Jahns

    Guest

    Thomas Jahns <> writes:

    > writes:
    >> 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.


    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

    --
    Brian Raven
    You tell it that it's indicative by appending $!. That's why we made $!
    such a short variable name, after all. :)
    -- Larry Wall in <>
     
    , Feb 21, 2005
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Taewoon Kwon

    Qustion about ithreads join

    Taewoon Kwon, Sep 10, 2004, in forum: Perl
    Replies:
    1
    Views:
    429
    Joe Smith
    Sep 15, 2004
  2. David Morel

    Is the ithreads implementation safe?

    David Morel, Sep 13, 2003, in forum: Perl Misc
    Replies:
    0
    Views:
    98
    David Morel
    Sep 13, 2003
  3. Walter Roberson

    Knight's tour in perl ithreads

    Walter Roberson, Feb 2, 2004, in forum: Perl Misc
    Replies:
    0
    Views:
    119
    Walter Roberson
    Feb 2, 2004
  4. Walter Roberson

    ithreads at runtime?

    Walter Roberson, Feb 3, 2004, in forum: Perl Misc
    Replies:
    3
    Views:
    96
    Walter Roberson
    Feb 4, 2004
  5. Micha³ Lesiak (bler)

    ithreads & memory

    Micha³ Lesiak (bler), Jul 18, 2005, in forum: Perl Misc
    Replies:
    10
    Views:
    171
Loading...

Share This Page