note
liz
<I>...the difference between a thread and a process...</I>
<P>
If you're using Perl threads, you shouldn't have to worry about whether it is actually implemented using processes or real threads™. That's why they're "Perl threads".
<P>
Having said that, to my knowledge, Linux is the only system where you can actually think of threads as processes, as having seperate program id's (pid's, $$). This allows modules as [cpan://Thread::Signal] to function in that environment. Win32 only knows about real threads and mimics fork() using threads. Other *nixes are somewhere inbetween. Some can fork() and have real threads (Solaris seems to fall in that group). But e.g. on Mac OS X (and presumably other BSD's), threads look as seperate processes, but can not be signalled.
<P>
<I>...never-ending sub (ie it's got a while (1) loop)m how can I stop it nevertheless?</I>
<P>
Use a shared variable in the while. So:
<code>
while (1) {
</code>
becomes:
<code>
while ($sharedvar) {
</code>
and reset the shared variable in another thread when you want to have the thread in question stop.
<P>
In that respect, you might also want to have a look at [cpan://Thread::Queue::Monitored] and/or [cpan://Thread::Conveyor::Monitored].
<P>
Hope this helps.
<P>
Liz
<P>
<B>Update</B>:<BR>
I forgot one other way to do this. This will only work if you are running under Linux for now. Use [cpan://Thread::Signal] to activate a handler that will do a [cpan://Thread::Exit]. No nice cleanup that way, but definitely effective ;-)
285423
285423