You may have been a bit longer in this business than I (who came to computers off studying architecture around 1989) but I haven't been asleep in the meantime. I also remember the times when a good word processor on the Atari ST (RIP) was worth ~250kBytes on disk; I had my first perl experience with v4.36, and was glad and proud with my simple coding and delighted with Gurusamy's port to the Atari.

That's for that, Father ;-)

But as for threads - set apart the usefulnes of threads, your statement "threads in unix are spelled fork" is blatantly wrong. Threads were invented for a reason which shurely didn't escape you. Which reason? There.

Do threads solve the issues they address, and at which price? Here we might start a discussion, not just saying "threads suck" ("No, they don't suck." - "Yes, they do!" -"NO!") and throwing in false statements in an inflamatory way.

While I also never had the need to use threads, did all I had to do with fork or an event driven model (Event back then, then POE) - so I'm included in that "we were accomplishing" -, I also have to say that "Using threads are like using globals" is misleading, that would be more appropriate "using threads is like using our()".

I agree with you saying "Using fork is like having everything be local to its code and data", which is fine as long as you just want it that way and never ever are in need of shared variables. If you need shared data, you have the option of delegating the data to an external instance or to share it somehow via classical IPC mechanisms, shared memory segments, message queues, pipes and such - but you basically need the same synchronisation mechanisms as with threads (in come semaphores), and sharing complex data structures is IMHO some hells more difficult using IPC.

--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}