On 26/02/06 14:14:55, Christian Biere wrote:
Manuel Tobias Schiller wrote:
> Well, blocking all other threads is a bad thing in itself, because
> I tend to lose button events when I can't poll them in time
> (remeber, button polling is done with ioctls, it's got nothing to
> do with the poll() syscall; poll() will only tell when a write to
> the device is possible without blocking). Besides, blocking all
> threads inside usleep() or inside poll() or select() is all the
> same to the application (it won't wake up in these 50 ms to poll
> the buttons when it's time to do so) and therefore the realisation
> of making the process block is not really that important, because
> streaming the mpeg data is not critical when it comes to timing
> (the kernel level driver has 16 kb buffers, for a 128 kbit stream,
> a full buffer lasts for a whole second), but button polling (which
> has to be done via ioctls) is timing critical, because this is
> what determines the responsiveness of the application. One should
> probably poll the button status 25 to 50 times per second; this
> won't take much time however, because the operation is reasonably
> fast, so the button polling thread can remain blocked most of the
> time.
Out of curiosity, I've tested how much CPU the following program uses
and how bad latency gets. The CPU is virtually idle and the latency
stays below 30 ms most of the time even when playing three videos to
utilize the CPU completely at the same time. Your button polling
thread wouldn't do anything else than this except using some
light-weight ioctl() calls instead of gettimeofday(), right? So I
don't think the button polling has to waste a lot CPU time.
[ C source code omitted ]
My suggestion would be to use such a helper process to poll for button
events and pass the collected events over a socket created with
socketpair(). Even if you use it for testing only, it might be useful
to sort out the timing issues. In your main process you can then
poll() for the button events without busy-loop alike polling. Of
course, without real-time scheduling there's no guarantee that all
button events are registered. If the CPU is rather slow or heavily
loaded, the 50 ms latency might not be achievable constantly. As far
as I understood, the problem is that these events cause no interrupt
and are also edge-triggered, meaning they're lost if you don't catch
them in time. I agree that handling the button events inside the
kernel is probably the best option.
--
Christian
Hi again,
thanks, I should have thought of this earlier. I have already tried to
put the mpeg data spooling in a seperate process which did not quite do
what I wanted it to because checking when the spooling process has
finished or killing it to skip to the next song becomes more involved
if done properly (I didn't have much time then and didn't do it
properly, and consequently, I ran into some nasty race conditions).
Race conditions seem easier to avoid with the event polling process (I
agree, it wouldn't need much cpu time at all - even on my 386 ;), on
the other hand, creating seperate processes is the first step towards
something like posix threads, so using them right away might be better
for the time being. I'll have to think about that.
Well, I agree that the button polling stuff should probably not be in
user space or the kernel but in the device's firmware, but at the
moment, I don't have time to go into one or two weeks of extreme
microcontroller assembly coding and reprogamming. But that is certainly
what is planned in the long run. Then, we can just read button events
from the device using read(), check for availability using poll() and
so on, button events will even generate interrupts. When I reach that
state of firmware sophistication, pth will certainly be the threading
library of choice.
Well, thanks again for the idea, I was stupid not to think of it.
Have a nice time everybody!
Manuel
______________________________________________________________________
GNU Portable Threads (Pth) http://www.gnu.org/software/pth/
Development Site http://www.ossp.org/pkg/lib/pth/
Distribution Files ftp://ftp.gnu.org/gnu/pth/
Distribution Snapshots ftp://ftp.ossp.org/pkg/lib/pth/
User Support Mailing List pth-users@gnu.org
Automated List Manager (Majordomo) [EMAIL PROTECTED]
