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

[Eric Noulard]

2007/6/20, Frederik Deweerdt <address@hidden>:
> >
> > Just a thought but if your BB "server" already know that there is
> > "several" client then I think you ought to create 1 new msg queue
> > by "client".
> >
> The thing I don't like here is the eternal CPU consumption for sending
> messages to a dead client. But this would work otherwise, yes. I could
> also periodically check whenever a client is dead or not. It just seemed
> weird to have to resort to that instead of having msgsnd scream :)

If you look at current sysv_bb_msgq_send(...) code you'll see
that we check the queue BEFORE sending PRECISELY in order
to avoid flooding:

retcode = msgctl(bb->priv.sysv.msg_id, IPC_STAT, &mystat);
        if (!(mystat.msg_cbytes > 2 * MAX_SYSMSG_SIZE)) {
                /* Non blocking send */
                retcode =
                    msgsnd(bb->priv.sysv.msg_id, msg, MAX_SYSMSG_SIZE, 
IPC_NOWAIT);

....

I do not remember WHY we did this but I think it was provisional
in order to keep "free space" in the queue
in case we wanted to be able to send some kind of "emergency" message.

Moreover you see that we send message in non -blocking way using
IPC_NOWAIT. This is done in order to have roughly constant execution
time for "bb_msgq_send".

We did this because most of the time the sender is a realtime task.
If this task is cyclic we want to be (almost) sure that the cycle time
does not vary because some external task/program
(for example tsp_bb_provider) is receiving the message.

In my opinion it's far better to continuously send message forever for
nothing than having varying execution time due to the fact that
the number of client is varying.

The current BB message queue usage was designed this way.

However I see your need does not "really" fits the current design
so I will propose you something in the next answer, to your
specs message.

--
Erk