|
![](/i/fill.gif) |
>> 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.
Seems like a conceptually simple model.
>> 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.
I would suggest that sending a channel over a channel is probably
trivial, but sending a channel over a socket is probably *highly* complex...
>> 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.
Oh. Really? I didn't know that...
Well, now I guess I understand why everybody gets so excited about
Haskell's concurrency support then. :-}
>> 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."
It's supposedly one of the big plus points of Java - not that I have
*ever* seen *any* Java program which actually supports plugins, mind you...
As an aside, GHC theoretically is supposed to support dynamic loading.
Good luck making it actually work though...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
![](/i/fill.gif) |