Orchid XP v8 wrote:
> So you mean each thread waits for messages to arrive, processes them, 
> maybe sends some other messages, and then waits for the next message?

Essentially, yes.

> Mmm... In C, an integer is a "first class" thing, but that doesn't mean 
> you can send it over a network connection, for example. They might mean 
> that these channels only work inside a single running instance of a 
> single program.

If you can send a channel over another channel, then all you need is to 
encapsulate channels over sockets and you're done. If you can't send a 
channel over another channel, then it isn't first class.

> Oh, OK. I assumed they all do what Haskell does

No. Generally, desktop languages that supported threading before multi-CPU 
machines were common either fake it or use OS threads. Any language with a 
"threadpool" structure in the library is probably one of these.

Java with green threads faked it, Java with real threads allocates threads 
one for one, C# uses real threads, Smalltalk fakes it, C and C++ tend to use 
real threads, etc.

Of course, java and C# can change the semantics to use lightweight threads. 
C and C++ are probably stuck unless they break compatibility with all the 
other thread languages. Smalltalk is probably stuck with its own threads 
because everything there is "too open".

> Ah, dynamic loading is fun.

It's important for long-running programs, things with plug-ins, etc. Even if 
it's just dynamic linking. Of course, given it's google, they might very 
easily say "crash out if you want to load a different implementation of 
something, because everything we write recovers automatically anyway."

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message