Re: Best Practice For Killing Thread?

At 11:25 -0800 11/3/03, Steve Schein wrote:
>  > The best way would be to use a shared array or shared hash (keyed to
>  > thread id) with a flag being set.  The thread will then need to check
>  > that flag every so often and shut itself down when the flag is set.
>  >>> Hey Elizabeth.  Sorry to bug ya again.  It seems there aren't too
>many posters (those who answer questions) here other than yourself.
>Hopefully, I'll be able to contribute on the answer side of things
>someday and let you get some work done!  For now, let me know when
>you're in southern California and I'll buy you a dinner for all the help
>you've been to me.

I hope to be able to make it to OSCON in Portland next year... 
that's as close as I will be to southern California for some time to 
come, I'm afraid...  ;-)


>  >>> To the issue - My first thought was to set up a mechanism as you've
>described but it doesn't work well with things like socket receive
>message commands which seemingly just sit and wait for new messages and
>block other activities.  In a true loop I could check the flag each
>iteration and exit. Am I being clear?

I feared as much, yes...


>  > Threads only have pids on Linux.  This is used by Thread::Signal (my
>>  version, from CPAN), which provides an API for sending signals to
>>  threads.  However, an exit() from a thread will stop all threads.  If
>>  that's the way you want to do it, you'd also need Thread::Exit (also
>>  by me, from CPAN).
>>
>>  You may also need to switch off safe signal behaviour if a thread is
>>  stuck in some kind of network operation.
>
>>>>  The good news is that it is Linux, but the bad news is that it is
>undesirable to stop all the threads.  I've read some of your previously
>perlporters posts to understand why this is.

Well, you'll want Thread::Exit and Thread::Signal.  Set up a signal 
handler for a specfic signal, and let that do an exit() (with 
Thread::Exit, that will only exit the thread).


Liz