Re: Stream venting (long)

[dennison@telepath.com]

In article <76baib$4ne$1@nnrp1.dejanews.com>,
  robert_dewar@my-dejanews.com wrote:
> In article <76aor7$l4q$1@nnrp1.dejanews.com>,
>   dennison@telepath.com wrote:
> > The problem is when to release the lock. You can't
> > acquire and release it after every call to the stream's
> > Read or Write procedures, or you get interleaved data.
> > You'd have to do it *manually* before the client's first
> > top level 'Write call and after their last. That means
> > the client has to do
> > it. Yuk.
>
> I already gave the (perfectly trivial) solution for this
> problem. Associate a lock with the stream. When a stream
> routine is called, claim the lock IF IT IS NOT ALREADY
> CLAIMED by you! On completion, release the lock IF YOU
> CLAIMED it on entry. This should be perfectly simple to
> program, and completely solves your problem.

Hmm. It appears you think my problem is with algorithmicly handling the
clients locking when locking is happening interally already. That's not the
case; my problem is making the clients do their own pre- and postprocessing.
That's a crappy interface. My code should be handling messy details like that
for them (not so incidently, removing one possible source for errors). They
should just be able to do a 'Write on their data structure and be done with
it.

--
T.E.D.

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