note Abigail-II <ul> <li>"Thread" is a buzzword, <code>fork</code> isn't. Of course, <code>fork</code> has clocked over 30 years of mileage, while threads are the new kid on the block. <li>Threads have been invented and reinvented. So we have kernel threads, green threads, posix threads, interpreter threads, etc. It's just like Java, it never works the same twice. <code>fork</code> is just <code>fork</code>, you just pull out your Stevens or other book from your bookshelf, and it just works reliably, with a clear and simple interface. <li>Inferior OSses don't have <code>fork</code>. <li>Threads mangle each others variables by default, and you need to explicitely guard yourself against that from happening. (Note that just *looking* at a variable can mean Perl changes the variable under the hood - it's not a safe operation.) <code>fork</code> is safe for your data, you need to explicitely share data (using shared memory for instance). <li>Compared to a select() loop (as provided by for instance POE), threads give you underterministic behaviour, while a select loop gives you deterministic behaviour. <li>Do you know which thread is going to handle a send signal? On any signal capable OS? I know when I <code>fork()</code>. </ul> 181655 181655