Re: SV: Threads

[Daniel Solaz]

Svanberg Liss wrote:
> Start to check out BeOS. I don't really know much about Be, but it claims to
> do just this, so it might be worth a look.

Not really.
It's just that library functions may spawn their own threads when
needed, but that doesn't mean you don't have to anymore.  Every window's
event loop runs in its own thread.  If you use the Media Kit classes to
play sound, some five threads may get created in the background without
you even noticing.  That's what they call 'pervasive multithreading' in
their marketing.

> You will simply not know what threads you have got in your program, so I
> think coding will actually be harder this way. And most old programs will
> break...

The BeOS thread API (see the Kernel Kit chapter of the Be Book) is quite
similar to the POSIX API: spawn, join, etc.  The fact that the whole OS
code is thread-safe and reentrant is nice, but you still have to take
care of your threads.  The only synchronization primitive available on
BeOS is the semaphore, and this makes things harder.  And yes, sometimes
you have to know what's happening in order to arrange things correctly.

> But, again, you might use SMP's better.

Or PVM.  Or MPI.
If you want really transparent threading, try the SCOOP extension to the
Eiffel language.  Someone finally implemented this, but I could not make
it work under FreeBSD (which has perfectly working POSIX threads).
Then there's the Erlang/OTP platform, which makes distributed
programming so easy that it seems too easy.

And now I shut up.
-Daniel