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,a0224dc3d1e52f3d X-Google-Attributes: gid103376,public From: dennison@telepath.com Subject: Re: Streams and Concurrency Date: 1998/12/31 Message-ID: <76g0nu$nsq$1@nnrp1.dejanews.com>#1/1 X-Deja-AN: 427440650 References: <76dhm3$rkq$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: Thu Dec 31 14:12:14 1998 GMT Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.5 [en] (WinNT; I) Date: 1998-12-31T00:00:00+00:00 List-Id: In article , eachus@spectre.mitre.org (Robert I. Eachus) wrote: > In article stt@houdini.camb.inmet.com (Tucker Taft) writes: > > > Furthermore, to support non-blocking read, you would need to add some > > kind of marker into the stream itself, I suspect, to be placed between > > "top-level" objects in the stream. Then, when you call the non-blocking > Since the non-blocking read would have to do read ahead to find > the marker, the marker doesn't really add anything. So you really > only need two sets of entries, one which does blocking read and > writes, and one set which is non-blocking. HOWEVER, the routines > underlying the Read operations for interprocessor communication and > I/O streams will have to be defined in terms of Stream_Elements, > because you will have to not only do read ahead, but you will have to > save the read ahead material in another (in memory) stream. Ahhh. I had thought of that approach. I discarded it because I'm talking real-time processes here. I don't have time to go copying large chuncks of data around in the context of the real-time process. It does solve the problem of handling objects w/ limited private fields, though. > Note that this is an somewhat special pattern. It is only of > interest in the presence of tasking and either multiple processors or > the like. And while it can easily be written in portable Ada 95, it > is one where low-level implementation support can significantly > improve performance. "Special" perhaps, but not all that odd. It can occur in *any* tasking program. In my 10 years of Ada use I've only worked on two programs that had no tasks. It doesn't take a multiprocessor to cause a task switch in the middle of a non-blocking operation. If you have tasks with different priorites it can happen. If your scheduling policy supports any kind of time slicing it can happen. Plus if the stream's Write procedure performs any I/O, its possible that a 'Write itself is a blocking operation. -- T.E.D. -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own