|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |