chooses to use the additional poll() flags, pth is able to
accomodate the application. Always building pth like this won't hurt
anything in the case that the application does not know about the
additional poll() flags.
A patch for the pth_poll_ev() problems follows.
Thanks,
Jason Evans
--- pth-1.4.1
I've been subscribed to this list for several weeks now, and have seen no
indication that someone is actually maintaining pth. There have been at
least 4 bug reports, 3 of which included fixes. I'd like to know if
someone is keeping track of all the fixes people are providing, since I
recently
it acceptable.
Thanks,
Jason
--
Date: Sat, 22 Jun 2002 16:38:18 -0700
From: Jason Evans [EMAIL PROTECTED]
Subject: Problems with poll()
To: [EMAIL PROTECTED]
pth_poll_ev() does not provide any support for POLLRDNORM, POLLWRNORM,
POLLRDBAND, or POLLWRBAND. This causes surprising errors
On Tue, Aug 27, 2002 at 01:59:21PM -0700, Archie Cobbs wrote:
Jason Evans wrote:
On Tue, Jul 30, 2002 at 08:29:53PM +0200, Ralf S. Engelschall wrote:
In case there are still any problems and/or patches around
we still have not included into the CVS state of Pth (see
http
On Thu, Nov 07, 2002 at 05:13:58PM +0100, Ralf S. Engelschall wrote:
After integrating lots of pending bugfixes and enhancements into
the official GNU Pth source tree I've rolled an official 2.0b0
version which is available from the OSSP project environment
under
On Fri, Nov 08, 2002 at 09:36:52PM +0100, Ralf S. Engelschall wrote:
Thanks for your feedback. Even more integrated fixes and changes now
await our testing. After mostly rewriting pth_poll(3) and pth_select(3)
in order to be more POSIX.1-2001/SUSv3 compliant we all should give it a
try before
On Sun, Jul 13, 2003 at 05:41:14PM -0700, Damon Hastings wrote:
If the context-switching overhead turns out to be too high, then I will do
exactly that. But it will mean maintaining state for each connection, and
that state will only grow more complex with future enhancements by myself
and
