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

[Frederik Deweerdt]

Hello Eric,

On Wed, Jun 20, 2007 at 01:50:10PM +0200, Eric Noulard wrote:
> 2007/6/20, Frederik Deweerdt <address@hidden>:
> >Hi,
> >
> >Current SysV BB implementation (function sysv_bb_msgq_send) doesn't return
> >an error code when the message queue is full. I think this is a bad idea,
> >as there is no way to find out if a message was really sent or not.
> 
> I'm not sure that sysV IPC guarantees that on msgsnd returns the
> message has ALREADY been sent..
Hm, I don't get it, I was expecting to get EAGAIN in errno:

EAGAIN     The message can't be sent due to the msg_qbytes limit for
           the queue and IPC_NOWAIT was specified in msgflg.

What I want to know, is if the msg queue is full or not. If yes, I want
to empty it to allow other clients to get their information.
> Moreover I'm not sure that we should introduce such an assumption.
> I may imagine networked implementation of message queue for which
> "was really sent" is not a easy question to answer.
> I would assume something more like "enqueued for sending".
I can see the problem, however, I think that the BB master (the one
sending sync), could use the fact that client n°3 lost its connection
and that it can't be notified anymore.
> 
> >I'd like to rely on error retcodes to find out if a client is dead or
> >not, and currently, this is not possible.
> 
> I'm not sure it is the "good" way to ensure client liveness,
> you may ask client to send you a ACK message on the same queue
> (or another one).
I didn't think of that one at first, it seems a bit fragile tought,
because depending on timing issues, your queue could fill up a prevent
other clients from notifying.
> 
> Nevertheless, you are right, I think you may replace:
> 
> else {
>               /* NOP */
> /*     LOG(BB_LOG_WARNING, */
> /*          "Blackboard::bb_snd_msg", */
> /*          "Cannot send msg <%d> bytes already queued>",mystat.msg_cbytes); 
> */
>       }
> 
> with appropriate retcode value assignment may be simply
>     retcode = BB_NOK
> 
> if you want more valuable retcode you'll have to define enum value
> currently we only have:
I think that -1 is OK, we just need to check errno for its value after
that.
> >Any thoughts on why this could be justified?
> 
> We should be able to silently ignore full BB message queue
> because BB message queue was primarily thought as a
> synchronization mean between user application using BB
> and a bb_tsp_provider.

I had a quick look, it looks like the case where there are multiple
clients of the BB works because the BB is shadowed at first, isn't it?
But that means that we cannot get to modify the BB with multiple users
of it?

My use case is more or less like sync, but I use the PID of the client
as mtype, so that I can tell several clients that value X vas
modified. Otherwise, only the first one that gets the msg is notified. If
one subscriber suddenly dissapears, the queue fills up and no one ever
gets the sync after a few messages.

So I think that this might still be a "legitimate" use of the BB msg
queues, what do you think?

> 
> The application send "bb_simple_synchro_go"
> and the provider "bb_simple_synchro_wait"
> (look at the code for the message content).
> 
> The application should run "as usual" even if the
> bb_tsp_provider is not running thus not consuming
> the synchro go messages.
Then, it should ignore BB_NOK depending on errno?
> 
> Nevertheless in this case the user app.
> MUST NOT be perturbed by ANY error related to BB message queue
> so I think most app. do not even check the retcode from
> "bb_simple_synchro_go".
> 
> In the end I think you may change the retcode of bb_sng_msg
> for a meaningfull one when the queue is full, it should not
> bother current BB suer app.
Do you refer to in-CVS implentations or wild BB out there? Obviously,
if they check for BB_NOK and then abort, they'd need a rewrite...
> 
> Anyone with counterexample please shout it here :))
> 
Listening too :)

Fred