Re: Stream venting (long)

[robert_dewar@my-dejanews.com]

In article <76doir$1ek$1@nnrp1.dejanews.com>,
  dennison@telepath.com wrote:
> Ahh. I see we have different ideas about what "client"
> means. To me the "client" of my stream package *is* the
> writer of the stream attribute routines. I have no clue
> how to write those routines for them, as I have no
> prior knowledge of what they want to write (or access
> into their packages). In fact, they may want to use the
> default routines in many cases. So we're stuck with the
> crappy interface.


This is getting more and more peculiar. Of *course* the
implementation of the stream routine itself cannot provide
atomicity. This is fundamental, since as you say, it cannot
know what is being written.

The only point in the system where you know what level of
atomicity is required is at the point where you write stuff
to the streams. This requires locks. There is no magic to
get rid of the need to lock here. If the built in stream
attributes were task safe (that would incidentally be a
very poor choice), then of course the locking would have
to be in the default attribute routines.

Of *course* the locking belongs in the attribute routines,
it could not be anywhere else. As for crappy interface, it
is perfectly trivial to make an interface that simply
allows:

   Stream_Lock;
   ...
   Stream_Unlock;

to be placed in each attribute routine for which atomicity
is required (these primitives would properly take care of
nesting).

(a) what is so crappy about this interface?
(b) how could it possibly be avoided

If you want to use tasking, you have to take responsibility
for allocating resources properly, there is no magic that
can do this for you.

Yes, the language could have been designed so that the
default attribute routines had this kind of locking, but
that would have been an extremely bad idea for two reasons:

a) user written stream attribute routines would have to
lock manually, and might easily not do so. But caller's
would expect automatic locking.

b) this locking would introduce nasty overhead in the
normal case at a point where efficiency is very important.

After all, we do not even bother to lock Text_IO
automatically, so two tasks cannot do Put_Line's without
worrying about locking. It would be bizarre to decide that
streams should behave differently.

Yes, the logging case is a legitimate one, but frankly I
would do things differently, I would create an agent,
either a task or a protected type, that was charged with
the responsibility of doing all necessary logging, that is
I would make a higher level interface to the logging
routines. If, as seems the case from your somewhat
confusing description, you insist on having individual
tasks execute stream attributes directly, then the locks
belong in the stream attributes, no other place for them!


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own