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.