Subject: pkg/23571: devel/pth is unable to read audio device in various packages
To: None <>
From: None <,>
List: netbsd-bugs
Date: 11/25/2003 21:08:29
>Number:         23571
>Category:       pkg
>Synopsis:       devel/pth is unable to read audio device in various packages
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Nov 25 21:16:00 UTC 2003
>Originator:     Michal Pasternak
>Release:        NetBSD 1.6.1
Good People With Bad Reputation
System: NetBSD 1.6.1 NetBSD 1.6.1 (GENERIC) #0: Tue Apr 8 12:05:52 UTC 2003 i386
Architecture: i386
Machine: i386

	devel/pth is GNU Lightweight Threads package, working mainly as
	a replacement layer for POSIX thread.
	On NetBSD-1.6.1 at the time of writing it is unable to read
	/dev/audio . I don't know about the underlying cause, but it
	could mean it is unable to read other special files as well.
	It could also mean a bug in underlying layers (libc?)
	The problem results in unability to record sound in packages
	like audio/sweep, wip/portaudio, wip/py-fastaudio, lang/python23-pth,
	lang/python22-pth and propably many other packages.


	1) install one of above packages
	2) try to record sound.
	Python's proof of concept:
	- we'll use this simple one-liner to demonstrate the bug:
		open("/dev/audio", "rb").read(10)
	- on non-pth Python (I have used 2.0.1):
	Python 2.0.1 (#1, Nov 25 2003, 21:42:48) 
	>>> open("/dev/audio", "rb").read(10)     
		- it reads the static. Good!

	- on a Pth-enabled Python you will wait for this read _forever_


        Fix is _crazy_, but first let me talk for a minute.
	All GNU Pth programs that utilize Pthread simulation are in
	reality a "standard", single-thread, event-driven applications.
	GNU Pth uses re-defined blocking functions, as you can easy
	check by running:
		grep pthread_read /usr/pkg/include/pthread.h
	Substituted read function (in reality, pthread_read) is declared
	in pth_high.c .
	I have debugged this and found out, that all programs stop
	at pth_high.c:788 , in pth_wait. 

	This stop is either caused by bad event mask set in pth_high.c:785
	(and no, adding PTH_EVENT_FD_EXCEPTION didn't help at all), or - 
	pth_event has some bugs, which occur while using /dev/audio .
	The thing, that helps is... adding PTH_UNTIL_FD_WRITEABLE in
	pth_high.c at line 785 .
	And, guess what? Sweep allows me to record my freestyle raps, I can
	finally write my Python VoIP software with py-fastaudio, everyone
	is happy.
	Send patch, you say.

	Someone with bigger knowledge than mine could write up a patch 
	for this . First, you need to check if it's only /dev/audio, or
	does it hit other devices as well . Second, we need to create
	a patch, that will apply only to devices, which are handled
	in a broken (blocking) way by Pth. And no, testing by fstat(2)
	in pth_high.c if the fd is a device won't give you proper results
	(it seems it can read other "devices" without blocking)