[PATCH.HURD] Limit the minimum timeout delay to 1us for hurdselect.c to avoid problems

2012-11-01 Thread Svante Signell
Hello, I'm currently working with an update of hurdselect.c in eglibc, and found a problem with non-blocking delays of value zero. This problem has been seen before for vi for select and a workaround hack is currently in the Debian version of eglibc-2.13. I have also seen this problem with my new

Re: [PATCH.HURD] Limit the minimum timeout delay to 1us for hurdselect.c to avoid problems

2012-11-01 Thread Samuel Thibault
Svante Signell, le Thu 01 Nov 2012 17:32:53 +0100, a écrit : --- ../hurdselect_orig.c 2012-10-21 22:55:26.0 +0200 +++ ../hurdselect_orig_timeout.c 2012-11-01 12:58:00.0 +0100 @@ -84,9 +84,13 @@ to = (timeout-tv_sec * 1000 + (timeout-tv_nsec +

Re: [PATCH.HURD] Limit the minimum timeout delay to 1us for hurdselect.c to avoid problems

2012-11-01 Thread Svante Signell
On Thu, 2012-11-01 at 17:44 +0100, Samuel Thibault wrote: Svante Signell, le Thu 01 Nov 2012 17:32:53 +0100, a écrit : --- ../hurdselect_orig.c2012-10-21 22:55:26.0 +0200 +++ ../hurdselect_orig_timeout.c2012-11-01 12:58:00.0 +0100 @@ -84,9 +84,13 @@ to =

Re: [PATCH.HURD] Limit the minimum timeout delay to 1us for hurdselect.c to avoid problems

2012-11-01 Thread Samuel Thibault
Svante Signell, le Thu 01 Nov 2012 18:04:35 +0100, a écrit : On Thu, 2012-11-01 at 17:44 +0100, Samuel Thibault wrote: Svante Signell, le Thu 01 Nov 2012 17:32:53 +0100, a écrit : --- ../hurdselect_orig.c 2012-10-21 22:55:26.0 +0200 +++ ../hurdselect_orig_timeout.c 2012-11-01

Re: [PATCH.HURD] Limit the minimum timeout delay to 1us for hurdselect.c to avoid problems

2012-11-01 Thread Svante Signell
On Thu, 2012-11-01 at 18:08 +0100, Samuel Thibault wrote: Svante Signell, le Thu 01 Nov 2012 18:04:35 +0100, a écrit : I have added 1, just like you tried to in your patch. to = (timeout-tv_sec * 1000 so it's ms. OK, 1ms seems to be a little long. If the time-resolution had been

Re: [PATCH.HURD] Limit the minimum timeout delay to 1us for hurdselect.c to avoid problems

2012-11-01 Thread Richard Braun
On Thu, Nov 01, 2012 at 06:20:50PM +0100, Svante Signell wrote: OK, 1ms seems to be a little long. If the time-resolution had been 1us it could have simplified the problem a lot. This is what my select_timeout branches in some hurd repositories is all about BTW. But with the recent work on

Rewriting hurdselect.c: How to detect that a file descriptor has disappeared?

2012-11-01 Thread Svante Signell
Hello, I'm working on a modified hurdselect.c, the poll() part, to enable file descriptors being bogus, as allowed by POSIX. That case is now solved, and the revent reported is POLLNVAL. What remains to do to is to return the POLHUP event (and POLLERR). Using modified code from gnulib,

Re: Rewriting hurdselect.c: How to detect that a file descriptor has disappeared?

2012-11-01 Thread Roland McGrath
The construct used in hurdselect is the mach_msg() function: __mach_msg (msg.head, MACH_RCV_MSG | options, 0, sizeof msg, portset, to, MACH_PORT_NULL) This function call only has parameters set for reading. Can a subsequent call using MACH_SEND_MSG parameters and messages be used to find