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: Eric Noulard
Subject: Re: [Tsp-devel] Flooding the BB msg queue
Date: Wed, 20 Jun 2007 13:50:10 +0200

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..
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'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).

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:

#define BB_OK        0
#define BB_NOK      -1
#define BB_SUCESS    BB_OK
#define BB_FAILURE   BB_NOK

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.

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.

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.

Anyone with counterexample please shout it here :))

--
Erk




reply via email to

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