tsp-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tsp-devel] Flooding the BB msg queue


From: Frederik Deweerdt
Subject: Re: [Tsp-devel] Flooding the BB msg queue
Date: Thu, 21 Jun 2007 11:19:51 +0200
User-agent: mutt-ng/devel-r804 (Linux)

On Thu, Jun 21, 2007 at 12:28:52AM +0200, Eric Noulard wrote:
> 2007/6/20, Frederik Deweerdt <address@hidden>:
> >On Wed, Jun 20, 2007 at 04:16:43PM +0200, Eric Noulard wrote:
> >> May be you can tell us the raw specification of what you need?
> >Yep, should have started with that one. I've several clients that
> >are working with the same black board. There's one master (the first
> >launching process), and N clients. When setting a variable in the
> >BB through the master, the clients are supposed to be notified that
> >something is happening.
> 
> OK I see, you really something like "broadcast" notification of the
> kind of pthread_cond_broadcast() with the eventual added value
> of "memorizing" the broadcast.
> Because here if the client comes late broadcast is lost whereas
> with message queue message may be received later.

That's true, but note that even in the sync case, getting old syncs
doesn't make really sense.

> >In that case a bb_snd_msg() is called with mtype
> >being the PIDs of the clients[1].
> 
> I assume your send 1 message for each client.
Yep, 1 message for every registered client. mtype == PID ensures that
the client only dequeues the message destined to him.
> 
> >Hence the problem: if one of them dies unexpectedly, we fill the queue,
> >and we don't even know that. So no one gets notified anymore.
> 
> OK. Now if you know the queue is full, other live client may ALREADY have
> lost notification for a while, even if the queue is not already full of
> the dead client message.
I don't think so, if I get an error as soon as I get it, I stop
everything, kill(client_pid[i++], 0) in order do discover which one
is dead, and then, I go on sending messages. Please note that the timing
is not important, only the fact that the value changed matters.

> In order to discover which is the dead client you'll have to "wait" until
> the queue is effectively full of dead client messages or beginning
> to dig the queue for trying to guess who is the dead.
> 
> If you had 1 queue per client then this issues disappears:
> if the queue is full then you may consider the client is dead
> (note that stalled client may well be considered dead because
> it stops consuming messages).
I see.
> 
> >[1] The PIDs are known because an REGISTER msg is sent after a client
> >successfully attaches to the BB
> 
> [...] 
> 
> Nevertheless you get the ideas, I love the daisy-chain idea
> from client very much because it make the load to be distributed
> on client. The price being a ?perhaps? greater delay because
> of this daisy chain.
OK, I think I'll end up with a per-client SysV queue with a
register/registered handshake. I'll let you know when the code is
posted. Thanks for your time and ideas :)

Fred




reply via email to

[Prev in Thread] Current Thread [Next in Thread]