In article <9c0jot$cah$1@s1.read.news.oleane.net>, Jean-Pierre Rosen says... > > >"Ted Dennison" a �crit dans le message news: >jL%D6.4582> I'd argue that ensuring finite blocking for clients is the >> *server's* responsibility. If the client is making an entry call, then .. >Interesting. I'd rather argue that in a client-server relationship, none of >the partners should trust the other one; each ensures its own security. It If we were talking TCP/IP (or perhaps annex E), I'd probably agree with you. But within the confines of a single program, I have to be able to count on my servers working properly, just like I have to be able to count on my normal subprograms working properly. >>In this context tenative/timed entry calls are one way to allow a >> server task to *also* be a client, without neglecting its own client(s). >That's one use of timed entry calls. I've met other ones... If we expand the concept of a "server" to include serving things other than Ada tasks (eg: a display, a request queue, a device), I think this would cover just about every use I can think of for timed entry calls. >There once was a famous, though unpublished paper by P. Kruchten about the >"Sex of tasks", that neatly discussed "male" tasks (callers only), "female" >tasks (accepters only), "hermaphrodites tasks", one special case of it being >the "gender bender", etc. I don't think I have it anymore, nor that Philippe >is still listening c.l.a... That's a shame. I'd be interested in what he had to say on the subject of "hermaphrodite tasks". I think there's a few sets of situations where they can be safe to use, if only one knows how to recognise the situation (and takes pains to keep the conditions the same, even through later redesigns). But nearly every time I've created one, I've regretted it. --- T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html home email - mailto:dennison@telepath.com