POV-Ray : Newsgroups : povray.off-topic : More Haskell fanning : Re: More Haskell fanning Server Time
30 Jul 2024 04:18:26 EDT (-0400)
  Re: More Haskell fanning  
From: Darren New
Date: 17 May 2011 17:58:59
Message: <4dd2efa3@news.povray.org>
On 5/17/2011 12:12, Orchid XP v8 wrote:
> 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.

> Right, OK. So the worst you can do (presumably) is steal lots of CPU time. (?)

Well, you can break the stuff that's shared, like the large binary store or 
the atom intern stuff.

> 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.

> Indeed. Erlang cares only about structure, not meaning. (Presumably the
> idiomatic way to distinguish between a ThreadID and a CustomerID would be to
> put an atom in front of it indicating it's "type".)

Pretty much, yes.

> 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.

>>> 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.

> GHC already generates "interface files" which are machine-readable files
> telling the compiler what's exported from each source module. Perhaps you
> could do some trick where you compare the old interface files to the new
> ones or something. (But this requires you to remember to not delete this
> files, which are usually considered "temporary", so probably some more
> specific mechanism is necessary.)

That was the kind of thing I was asking about, yes.

> Does Erlang not permit recursive definitions then?

Not of data. If "list" is already defined, you can't assign to "list" again.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.