Re: Bug#47896: MS_SYNC Macros Missing from Hurd development environment
Hi, Aurelien Jarno, le Sat 18 Feb 2006 23:32:50 +0100, a écrit : > It seems the msync() function has been implemented on Hurd since the > bug has been reported, at least there is now a sysdeps/mach/msync.c > file which seems to do something. The macro MS_SYNC has been added and some code has been added, but that's not for GNU Mach (since it doesn't define VM_SYNC_SYNCHRONOUS), so it's half-fixed: programs can compile, but they'll always get ENOSYS. Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#79358: is select still broken on hurd ?
Hi,
(summary for the recall)
> things like select(1,[0],[],[],[0,0..999]) always return 0 immediately
About the 0..999 range, it's just that the timeout value is divided (and
rounded down) by 1000.
Now, we have a pile of issues: in gnumach's ipc_mqueue_receive(), if
time_out is zero, the function returns MACH_RCV_TIMED_OUT even if a
message is ready. But anyway, since by design select() on the Hurd is
not necessarily synchronous (since it implies querying a server), the
reply can't be ready so fast.
Actually, on the Hurd, a timeout of 0 probably doesn't make sense (since
we at least need to give back cpu to the server). What I'd propose is
the attached patch (not tested), that rounds up the timeout value, and
in the case of 0, uses 1 (so as to give the server an opportunity to
answer).
Comments?
Samuel
Index: hurd/hurdselect.c
===
RCS file: /cvs/glibc/libc/hurd/hurdselect.c,v
retrieving revision 1.6
diff -u -p -r1.6 hurdselect.c
--- hurd/hurdselect.c 2 Apr 2002 04:41:45 - 1.6
+++ hurd/hurdselect.c 8 Jun 2007 17:27:45 -
@@ -50,10 +50,7 @@ _hurd_select (int nfds,
error_t err;
fd_set rfds, wfds, xfds;
int firstfd, lastfd;
- mach_msg_timeout_t to = (timeout != NULL ?
- (timeout->tv_sec * 1000 +
- timeout->tv_nsec / 100) :
- 0);
+ mach_msg_timeout_t to;
struct
{
struct hurd_userlink ulink;
@@ -75,6 +72,15 @@ _hurd_select (int nfds,
if (sigmask && __sigprocmask (SIG_SETMASK, sigmask, &oset))
return -1;
+ if (timeout == NULL)
+to = 0;
+ else
+{
+ to = timeout->tv_sec * 1000 + (timeout->tv_nsec + 99) / 100;
+ if (!to)
+ to = 1;
+}
+
if (pollfds)
{
/* Collect interesting descriptors from the user's `pollfd' array.
Processed: closing 38658
Processing commands for [EMAIL PROTECTED]: > # Automatically generated email from bts, devscripts version 2.10.4 > close 38658 Bug#38658: hurd: keyboard layout configuration 'close' is deprecated; see http://www.debian.org/Bugs/Developer#closing. Bug closed, send any further explanations to <[EMAIL PROTECTED]> > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: closing 144545
Processing commands for [EMAIL PROTECTED]: > # Automatically generated email from bts, devscripts version 2.10.4 > close 144545 Bug#144545: hurd: init scripts don't fsck extra partitions 'close' is deprecated; see http://www.debian.org/Bugs/Developer#closing. Bug closed, send any further explanations to Robert Millan <[EMAIL PROTECTED]> > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
libgl1-mesa-glx
Hi, There is some issues with packages that depend on libgl1-mesa-glx | libgl1: on the Hurd we only build libgl1-mesa-swx11 which provides libgl1, but buildd isn't smart enough to install it. A solution would be to ask maintainers to fix into libgl1-mesa-glx [!hurd-i386] | libgl1-mesa-swx11 [hurd-i386] | libgl1 ? In the meanwhile we may want to install libgl1-mesa-swx11 by hand on the buildd, so that these packages will go fine. Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#79358: is select still broken on hurd ?
At Sat, 9 Jun 2007 01:30:49 +0800, Samuel Thibault <[EMAIL PROTECTED]> wrote: > Actually, on the Hurd, a timeout of 0 probably doesn't make sense (since > we at least need to give back cpu to the server). What I'd propose is > the attached patch (not tested), that rounds up the timeout value, and > in the case of 0, uses 1 (so as to give the server an opportunity to > answer). > > Comments? The problem is quite suble. Here is how SUS describes select: If none of the selected descriptors are ready for the requested operation, the pselect() or select() function shall block until at least one of the requested operations becomes ready, until the timeout occurs, or until interrupted by a signal. The timeout parameter controls how long the pselect() or select() function shall take before timing out. The theory is that we don't trust the server to honor the timeout: it may be malicious and trick the client into waiting forever. However, there are enough ways in which we rely on the server for correct operation that using the Mach timeout mechanism to preempt the server doesn't bring any additional safety. Instead, I think, we should pass the timeout directly to the server and rely on it to honor the timeout according to the specification. Neal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
