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

[Frederik Deweerdt]

On Wed, Jun 20, 2007 at 03:23:10PM +0200, Eric Noulard wrote:
> 2007/6/20, Frederik Deweerdt <address@hidden>:
> >
> >Hello Eric,
> 
> Hi Fred,
> 
> >>
> >> 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.
> 
> I meant that:
> 1) Knowing if message queue is full is easy and you can rely on it.
> 2) Knowing if message has been delivered, enqueue, taken into account
>    by the systems etc... when msgsend returns (with no error) is another 
> issue.
> 
> If you only need 1) then it's OK.
1) is enough. I don't care what the client does with the event message,
I just don't want the queue filling so that alive clients don't get the
notification anymore.
> >> 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.
> 
> Yes it is fragile.
> The fact is the BB msg queue was not meant to be multi_client.
Do you think it is worth the work then? As you suggest, I can't just
create another msg queue, and the problem is solved. I'm just thinking
that this limitation may be artificial. I see the limitiation as only
a consequence of the fact that we don't know if the msgsnd failed or not.

I'm thinking that maybe checking errno even if BB_OK is returned could
be OK, but it sounds like a hack to me.
> 
> >>
> >> 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?
> 
> It doesn't works.
> It look as if it works, but in fact your several BB client take
> the sync from one another, for a test:
> 
> launch bb_simu -s
> then launch 1 bb_tsp_provider + 1 tsp client
> works as usual
> 
> the
> launch a seconf bb_tsp_provider on the same BB
> then you will see your tsp client hogging because
> the second bb_tsp_provider "steal"  synchro from the first one :(((
:) too quick look then.
> 
> >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 choice to make here is the following:
> 
> Should we keep BB message queue "as-is' for multiple subscriber or not?
> 
> 1) If yes then you'll have to flush for dead client but it costs time
It does cost time, but I think that:
1) The application should do it if needed, ie this shouldn't be the job
of libbb
2) It's not that much time (kill*possible PIDs + msgrcv*nb_of_messages)

Fred