[Live-devel] Synchro problem and isCurrentlyAwaitingData()

[Cristiano Belloni]

Hi to all,
I wrote a custom shared memory source. it inherits from FramedSource.
The shared memory is synchronized via Linux semaphores (simple 
producer-consumer algorithm), but since I didn't want to subclass 
TaskScheduler, I still use a "dummy" file descriptor-based communication 
with live555. In pseudocode:


~~~Client (without live555):

wait on semaphore_empty (blocking)
copy frame in shared memory
write one byte in a dedicated FIFO (this should wake up live555' 
TaskScheduler select())
post on semaphore_fill

~~~Server (with live555, in SharedMemSource::incomingPacketHandler1())
[turnOnBackgroundReadHandling is called in doGetNextFrame]

wait on semaphore_fill (blocking)
read one byte from the dedicated FIFO (to flush the FIFO buffer)
copy frame from shared memory
post on semaphore_empty

This works. Altought the blocking wait on semaphore_fill might make you 
wonder, the client wakes up my source with the write() in the dedicated 
FIFO and immediately posts on semaphore_fill, so the server almost never 
waits, and if it does, it doesn't block for a really small time.

The problem is that, after a while (1 or 2 hours usually), the client 
does its cycle and the server never wakes up. It *doesn't* get stuck on 
the wait, I checked: it simply never wakes up, as if the client write() 
was lost (but it *always* succeed on the client side) or the select() 
didn't wake up even if the write succeeded.

I would like to emphasize this: the server *never* gets stuck forever on 
its wait. When it gets stuck, the client is one frame ahead of the 
server, incomingPacketHandler1() simply is never called anymore and the 
wait is not even reached.

At this point, I have two questions:

1) In your knowledge, can the select() not wake up even if a write() on 
the other side succeeded? If it can, how is it possible? Note that the 
system is an embedded ARM processor, and it could get quite busy while 
acquiring and streaming video.

2) First thing I do in SharedMemSource::incomingPacketHandler1() is to 
check for isCurrentlyAwaitingData(). If it's false, I simply return 
before doing all the cycle, and this happens quite often. What's the 
meaning of isCurrentlyAwaitingData()? I mean, if the select() in 
TaskScheduler returned, some data must be present on the 
file/fifo/socket. How is it possible that the select() did return but 
still there's no data available? I'm getting really confused on this.

Thanks and regards,
Cristiano Belloni.


-- 
Belloni Cristiano
Imavis Srl.
www.imavis.com <http://www.imavis.com>
belloni at imavis.com <mailto://belloni@imavis.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20110406/0b4c7167/attachment.html>