Re: Multiple entry tasks

["Jean-Pierre Rosen" <rosen@adalog.fr>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2775 bytes --]


"Ted Dennison" <dennison@telepath.com> 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 presumably it
> *needs* the server to do something. So if the client is going to time out
of the
> call, it will probably need to come back and make the same entry call
later. If
> the sever *still* won't service the call, the client is really infintiely
> blocking, just with a loop instead of a single block.
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
is true that if the client times out, it will often come back later. Mut in
the meantime, it could ask on the console "Server not responding, try
again?", or try a different server, or just report a failure to upper levels
("connection lost"), or....

> To prevent dead/livelocks, its really best to think of tasks in terms of
clients
> and servers. Tasks making entry calls are clients, and accepting tasks are
> servers.
Agreed

>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).
> However, for this to work, the server task called by your hybrid
client-server
> task's *must* at some point block (with no time-out) on the hybrid's
entry. If
> the server task has a timeout in its accept, there's a possiblity that the
> timeouts of the two tasks will sync up, with the result being that they
will
> never (or very rarely) both be ready for the rendezvous. You might be able
to
> arrange this properly at first, but its quite common to discover the need
to add
> a timeout to a server's accept statment later in debugging or
maintainence, and
> there's no simple way to even see that there's a client somewhere in the
system
> that will be hosed by this. To top it off, the fix to the client is likely
going
> to have to be a redesign. Yeeeeach.
That's one use of timed entry calls. I've met other ones...

> Typically if you find the need for a client-server task, it is much better
to
> just use another task or protected object to internally queue up requests
to act
> as a sort of client/server "gender-bender".
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...

--
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr