On 26/02/06 11:23:43, Christian Biere wrote:
Manuel Tobias Schiller wrote:
> I tried to experiment further by adding an idle thread with minimal
> priority to the application which simply usleeps 50 ms (blocking
> all other threads as well); this approach made the cpu usage drop
> to about 35% to 45%, but this is still way above what can be done
> with blocking I/O.
If it's acceptable to block all other threads, wouldn't it be more
appropriate to use poll() or select() with a 50 ms timeout instead
of usleep()? Albeit you probably want a higher timeout to prevent
that the process gets unnecessarily scheduled.
--
Christian
Christinan, thanks for taking the trouble the read my post.
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.
Well, unless someone comes up with another idea, I should probably port
my app to posix threads, or maybe implement button polling and lcd
spooling as a kernel level thread (I hesitate to do this though,
because debugging a running kernel is difficult at best ;), and I tend
to produce quite a lot of machine lockups in the kernel when I have to
learn a new concept like kernel level threads while making sure that
the different parts of the driver don't get into each others way, at
least that's what my experience with programming this driver has taught
me in the past).
Well, I like pth anyway and learned a lot while using it. Maybe it's
just not suitable for the use I intend to put it to. But then, it
doesn't have to; after all, serving a homemade hardware mp3 player for
the printer port is probably not what pth was designed for. ;)
Thanks again, and sorry to bother you with this.
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]
