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]

Reply via email to