From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,71daebeb6145ebb6
X-Google-Attributes: gid103376,public
From: dennison@telepath.com
Subject: Re: Stream venting (long)
Date: 1998/12/29
Message-ID: <76aor7$l4q$1@nnrp1.dejanews.com>#1/1
X-Deja-AN: 426757108
References: <768sng$6r9$1@nnrp1.dejanews.com>
 <769g3r$moq$1@nnrp1.dejanews.com>
X-Http-Proxy: 1.0 x2.dejanews.com:80 (Squid/1.1.22) for client 204.48.27.130
Organization: Deja News - The Leader in Internet Discussion
X-Article-Creation-Date: Tue Dec 29 14:26:48 1998 GMT
Newsgroups: comp.lang.ada
X-Http-User-Agent: Mozilla/4.5 [en] (WinNT; I)
Date: 1998-12-29T00:00:00+00:00
List-Id: <comp.lang.ada>

In article <769g3r$moq$1@nnrp1.dejanews.com>,
  robert_dewar@my-dejanews.com wrote:
> In article <768sng$6r9$1@nnrp1.dejanews.com>,
>   dennison@telepath.com wrote:
> >   1. Stream 'Writes and 'Reads are inherently task
> >      unsafe. Possible solution 1a: You can of course try
> >      to implement your stream in a
> >      task safe manner. But as a stream implementor all
> >      you will see is a series of
> >      Write calls. A single 'Write from the client will
> >      cause an indeterminate number of these. There's no
> >      way to tell if a Write or Read call is the first
> >      or last in a series. If you need to make the enitre
> >      composite type's 'Write or 'Read atomic, you're SOL.
>
> I find this complaint bizarre, I must not understand it
> properly.
>
> First, the idea of different tasks writing asynchronously
> to a common stream seems an entirely bizarre program
> organization.

The bizarre program orginization you refer to is commonly called "logging".
It is also a good way to implement checkpointing or persistent objects,
unless you really *want* one file per task. Hmmm...Now I guess in my
particular situation I could use one file per task...perhaps that's the
solution.

> Second, if you really *do* want such an organization, it
> seems quite easy to program stream functions so that they
> are properly atomic. I see no difficulty in doing this.
> You just need a single lock, with a test that avoids
> messing with it if it is already set.

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.

--
T.E.D.

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