<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-15">
</head>
<body text="#000000" bgcolor="#ffffff">
Hi to all,<br>
I wrote a custom shared memory source. it inherits from
FramedSource.<br>
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:<br>
<br>
<br>
~~~Client (without live555):<br>
<br>
wait on semaphore_empty (blocking)<br>
copy frame in shared memory<br>
write one byte in a dedicated FIFO (this should wake up live555'
TaskScheduler select())<br>
post on semaphore_fill<br>
<br>
~~~Server (with live555, in
SharedMemSource::incomingPacketHandler1())<br>
[turnOnBackgroundReadHandling is called in doGetNextFrame]<br>
<br>
wait on semaphore_fill (blocking)<br>
read one byte from the dedicated FIFO (to flush the FIFO buffer)<br>
copy frame from shared memory<br>
post on semaphore_empty<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
At this point, I have two questions:<br>
<br>
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.<br>
<br>
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.<br>
<br>
Thanks and regards,<br>
Cristiano Belloni.<br>
<br>
<br>
<div class="moz-signature">-- <br>
<title></title>
Belloni Cristiano<br>
Imavis Srl.<br>
<a href="http://www.imavis.com">www.imavis.com</a><br>
<a href="mailto://belloni@imavis.com">belloni@imavis.com</a><br>
</div>
</body>
</html>