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: robert_dewar@my-dejanews.com Subject: Re: Stream venting (long) Date: 1998/12/31 Message-ID: <76etuo$uel$1@nnrp1.dejanews.com>#1/1 X-Deja-AN: 427330379 References: <768sng$6r9$1@nnrp1.dejanews.com> <769g3r$moq$1@nnrp1.dejanews.com> <76aor7$l4q$1@nnrp1.dejanews.com> <76baib$4ne$1@nnrp1.dejanews.com> <76de7d$opb$1@nnrp1.dejanews.com> <76dh6m$r63$1@nnrp1.dejanews.com> <76doir$1ek$1@nnrp1.dejanews.com> X-Http-Proxy: 1.0 x2.dejanews.com:80 (Squid/1.1.22) for client 166.72.81.84 Organization: Deja News - The Leader in Internet Discussion X-Article-Creation-Date: Thu Dec 31 04:18:33 1998 GMT Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.04 [en] (OS/2; I) Date: 1998-12-31T00:00:00+00:00 List-Id: 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