>> My understanding is that Unix is *great* at letting multiple processes
>> read the same file - it's *stopping* them doing this that's hard.
>
> Well, there is that, yes.

It amuses me that there were operating systems 20 years ago that could 
do this better than Linux. It also amuses me that there exists something 
that Windows can actually do better than Linux.

(I gather it's a similar story for figuring out when a file changed...)

>> Come to mention it, what's Erlang's thread scheduler like? Does it
>> just do
>> round-robin for all threads ready to run, or can you assign thread
>> priorities and stuff?
>
> I don't think there's any priority stuff that I remember.

Certainly I've often wished you could assign priorities to Haskell 
threads. But, unfortunately, the thread scheduler doesn't support that.

For that matter, it doesn't support querying how many threads are 
currently running either. Or what their relationships are. Or, indeed, 
anything about them.

(The other day, I was looking at Java, and was amused to note that "each 
thread has a name for identification purposes. Thread names do not need 
to be unique." Well, uh, they do if you want to use names to identify 
threads. :-P Silly Java...)

>> Presumably it just means that if you create more than 2^31 Haskell
>> threads,
>> the ThreadID counter will overflow and half the standard library will
>> malfunction...
>
> It might not even mean that, if nobody does any comparisons or math with
> them.

Testing for equity will still work. I think the only time ordering 
comparisons happen is if you store thread IDs in a BST - and then the 
ordering is arbitrary, it just needs to be total.

Now, if some library somewhere is trying to use thread IDs to infer 
which order threads were created in, *that* will break nicely.

So I guess the libraries don't break until you have 2^32 threads then.

>>>> You can upgrade the code, but unless you upgrade it all at once, both
>>>> versions need to speak the same wire protocol.
>>>
>>> Again, list of three integers vs list of seven integers.
>>
>> There's more to a wire protocol than what types you exchange. (There's
>> ordering, for example.)
>
> Well, yes, if you have two versions of Erlang that don't speak the same
> protocol as the other, they won't connect.

I was thinking more about two versions of the same program. Presumably 
they'll connect, but malfunction.

>> Does Erlang not permit recursive definitions then?
>
> Not of data. If "list" is already defined, you can't assign to "list"
> again.

Neither can you do this with Haskell. But the definition of "list" can 
refer to "list" itself.

Post a reply to this message