[prev] [thread] [next] [lurker] [Date index for 2005/04/25]
On 25 Apr 2005, Peter da Silva wrote:
>> My recollection was that the language specification said that the
>> runtime environment MUST do enough type checking to be sure you couldn't
>> reinterpret random memory as other random memory, but I could be wrong.
>
> That dosn't require any type checking at runtime, if the input language
> is completely statically typed checked.
Nor does it. Thanks - that makes that clearer, I hope, in my head.
[...]
>> That doesn't gel with the division I heard, which suggests that my
>> memory is wrong, or different people use this detailed breakdown
>> differently. Hrm.
>
> I don't know which official taxonomy you're talking about, I'm just talking
> about what the language's model exposes to the programmer.
I don't know it was official, but it seemed to be pretty broadly useful.
I think that I had misunderstood, or remembered, it, though, since your
explanation makes it make no sense.
[...]
>>> The problem with RPC is it puts you in lockstep with the idiot over on
>>> the other side, so even if you're not sharing state with him you're
>>> sharing execution context with him by proxy.
>
>>> It's better than just shoving your arm up the concurrency-beast's rear
>>> without so much as a rubber glove, but it's still unpleasant.
>
>> Last time I dealt with an RPC system it was asynchronous,
>
> Perhaps I don't understand what's RPC and what's interface then, but I was
> under the impression that at the language level an RPC was a rendezvous
> operation like an ADA message.
I think it may have been originally; IIRC, DCE and thus Windows RPC is
implemented that way. CORBA, at least, claims RPC and has asynchronous
operation tucked away somewhere within it as I recall.
My last call was an awful "middleware" system that way being used to
make life vastly more difficult for everyone involved in the particular
banking system. Theoretically, it gave value. Practically, they never
used any of that value, so it just made things harder.
Anyhow, what I was thinking of when I said RPC was "any tool that
automatically generates local stub code for message passing."
>> It always looked like it was going to be an academic project to me,
>> though, so I never put too much effort into learning it.
>
> Well, Bell Labs was using it in production.
>
>> Given that, I don't even know if they used a lot of threads, or not.
>
> No threads at all: fork() was it.
I think that Linux has actually taken the best path here: they provide
a 'clone' system call which you tell exactly how much state you want to
share with the other thread (or process).
fork() is share nothing, threads are share everything, and you can do
other stuff if you really want to like share memory but not file table,
or whatever.
That way the few tasks that *do* benefit from threads can take advantage
of them, and you can do equally clever things with other sharing models.
Of course, all of it is non-portable, which is a source of hate, but
hey, we can dream.
[...]
>>> Putting te MIME type in the file system, though, is a great way to end
>>> up with all the problems that Mac OS Finder Info can cause when it
>>> goes just the slightest bit wrong.
>
>> Maybe. I still cling to the idea that type identification can be
>> useful, since everyone wants to do it, and everyone does it differently
>> and badly.
>
> As far as I'm concerned there's only been one lot that ever did that kind
> of thing correctly, and ironically they were a videogame company.
>
> FORM nnnn 8SVX NAME 000A "Pan Flute" AUTH 0011 "Electronic Arts" ...
So you mentioned. I never worked with AIFF format files, except as an
end user, so I don't have much practical experience there.
Daniel
--
Sometimes a scream is better than a thesis.
-- Ralph Waldo Emerson
There's stuff above here
Generated at 01:00 on 03 May 2005 by mariachi 0.52