Subject: Re: both pth and pth-syscall?
To: None <tech-pkg@netbsd.org>
From: Luke Mewburn <lukem@netbsd.org>
List: tech-pkg
Date: 06/04/2002 12:39:01
On Sat, Jun 01, 2002 at 11:36:30PM +0200, Joachim Koenig-Baltes wrote:
| On Sat, 2002-06-01 at 14:27:40, Rene Hexel wrote:
| > BTW, I've been running with pth-syscall (focibly injected in place of
| > a pre-existing pth) for a couple of days, without any problems so far.
| > I have about 50 packages installed that depend on pth (most of them
| > gnome packages). So it seems like the syscall-hard problems of earlier
| > versions have been fixed ...
|
| I?ve been running a lot of packages with a pth package compiled
| with '--enable-syscall-hard' on i386 for over a year now, even Zope runs
| without problems after enabling threads in python.
|
| So for the time being (until nathan's scheduler activations give NetBSD
| native thread support) we should enable syscall-hard for the pth package.
After following this thread, I modified my local pth package to
--enable-syscall-hard, and after doing a "make replace" on devel/pth,
I've observed that at least the pth-using packages I regularly use
(mozilla and xmms) perform as well or better than the existing pth.
In the case of xmms, it takes 2-3 seconds of certains types of
activity on my X server to pause the sound when pth is using
--enable-syscall-hard, versus the almost instant pause with the
previous version.
Also, I was experimenting around with the GRIP cd ripper (from a pkg PR),
and noticed that it didn't function without pth with --enable-syscall-hard.
In summary, this is another vote for switching devel/pth to
--enable-syscall-hard and deprecating devel/pth-syscall
Luke.