bugThe eXtended osip library - Bugs: bug #26018, Lost events

 
 

bug #26018: Lost events

Submitted by:  None
Submitted on:  Thu 26 Mar 2009 08:19:11 PM UTC  
 
Category: NoneSeverity: 3 - Normal
Item Group: NoneStatus: Fixed
Privacy: PublicAssigned to: Aymeric MOIZARD <aymeric>
Open/Closed: Closed

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Fri 31 Jul 2009 06:39:28 PM UTC, comment #6:

Hi Aymeric,

I'm sorry, but I don't see how using select() helps in the matter. I must be missing something in your API.

When I read that code (the same goes for _wait, by the way), what I see is a race between the thread that produces events and the one that consumes them.

What is supposed to happen if between the time select() returns and the time you do the read, an event is posted on the pipe?

Your read() call will return 2 of those "w", but the caller of _get/_wait will only ever see one event, because those functions only return one event. Unless of course the caller is supposed to check some "next" field in the eXosip_event_t structure, but that would open a locking can of worms.

There is actually another race in _wait: the first call to select() seems to be used to purge the pipe so if a new event was posted between the call to osip_fifo_tryget(), you lose it and you'll have to wait for the timeout in case nothing else comes before.

What I expect in _get/_wait is for them to only ever block if there's truly nothing more in the queue. I don't see how that can happen in the current code. Unless, as I said, there is a way for the user to purge the queue by themselves before going back to _get/_wait, but not only this would be highly surprising as far as _get/_wait APIs go, but I don't see anything in the documentation indicating there is such a way anyway.

Sorry it took me so long to reply.

Quentin Garnier.

Anonymous
Mon 11 May 2009 04:14:00 PM UTC, comment #5:

You're right. Let me go deeper in the analysys.

First, in previous post: I've been unclear. I advise to not use eXosip_event_get, but eXosip_event_wait where the problem should not appear.

jpipe_read is not supposed to be there, it's only here
to empty the socket so it doesn't become full. The reason
is that the pipe is NOT supposed to be used with _get but
still get filled. (That's why there is no reason to use
1 instead of 499: it's just to empty the socket buffer).

So the real behavior is supposed to be a non-blocking read
on the pipe. Please check the new method svn, if it fits you.

Please also be kind with me: I'm doing my best for the last 10 years in various open source project and sometimes it's not enough for people, but that's the way it is! There is only 24h per day in my life!

Tks for your understanding and report!
Aymeric

Aymeric MOIZARD <aymeric>
Project AdministratorIn charge of this item.
Mon 11 May 2009 03:23:03 PM UTC, comment #4:

Well, obviously I use _get. And the first thing _get does is a read on the pipe. I don't care if you don't want to fix it, but don't tell me there's no bug there.

Anonymous
Thu 07 May 2009 10:22:39 AM UTC, comment #3:

This is wrong: at least in latest svn:

using exosip_event_wait (which is the one I use):

It will wait call "osip_fifo_try_get(eXosip.j_events);" even if there is nothing in the descriptor.

It is not possible to put long values for arguments of eXosip_event_wait(tv_s, tv_ms) because you might met
your issue.

Aymeric

Aymeric MOIZARD <aymeric>
Project AdministratorIn charge of this item.
Wed 06 May 2009 03:45:31 PM UTC, comment #2:

shrug But I can't get all the events in time, because the next time eXositp_event{_get,_wait}, it blocks waiting to get more bytes on the pipe without checking if there's already something ready in the event queue.

Anonymous
Fri 27 Mar 2009 08:41:13 AM UTC, comment #1:

Obviously, the current implementation require that you take ALL events even if there is only one byte to read in the socket/pipe: not just one event.

You can only assume that there is no other events in the loop if both the pipe & the event fifo are empty.

Aymeric

Aymeric MOIZARD <aymeric>
Project AdministratorIn charge of this item.
Thu 26 Mar 2009 08:19:11 PM UTC, original submission:

The way the event queue works makes it pretty much impossible not to lose events. In the case several events are generated before the user had a chance to call eXosip_event_get() or eXosip_event_wait(), as many "w" as there are queued events will have been written to the pipe. And because _get/_wait do a read of size 500 (where did that come from anyway?), it will eat all of them in one go, and block/timeout when the user does the next loop.

The fix is obviously to use the same read size as the write size, 1. All in jevents.c.

Quentin Garnier.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by aymeric (Posted a comment)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 11 May 2009 04:14:00 PM UTCaymericStatusWont Fix=>Fixed
    Fri 27 Mar 2009 08:41:13 AM UTCaymericStatusNone=>Wont Fix
      Assigned toNone=>aymeric
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup1