Re: Hurd CVS and X Debugging [Was: Re: Plans for X]
On Tue, Oct 24, 2000 at 03:26:10AM -0700, Steve Bowman wrote:
> > > Doesn't fix the problem though. I looked at the X mouse code
> > > a bit and it's opening in non-blocking mode. Opening it in blocking mode
> > > may hang and we'd have to do ioctl to change mode.
> > Although supported by glibc, I don't know if change open modes is supported
> > by the current kbd,mouse servers. I think I really have to audit the kbd and
> > mouse server code, it is quite old, and was never seriously revised.
> > Note that the same servers work with 3.3.6 just fine, and I don't think we
> > have identified the heart of matter.
> > > Really, this needs
> > > to have some error checking and retry logic. Kbd is probably the same.
> > Although such code would help here, it shouldn't be necessary. kbd and mouse
> > should come up and respond to the open call just fine.
> ACK. The problem isn't X here. I think it'd be more robust for a
> non-blocking open to retry on failure; maybe I'm thinking of NBIO after
> open when EWOULDBLOCK can be returned. This isn't listed as a possible
> E return for NB open (but I only checked man, not the source).
Yes, read on NB open'ed file can return EWOULDBLOCK, that's what the NB is
all about. The open() call should not block either, but there is little
reason to do so anyway. There is another bug in kbd, but I think unrelated,
where opening kbd a second time while its open kills it. However, the
problem here is that open() returns EINTR, and I really don't see how this
can happen in the Hurd at all (EINTR is returned for example when an RPC is
interrupted, mmh.) Any ideas anyone?
> In any case, I think the mouse is OK wrt this issue anyway as I mentioned
Yes, also strange, because the code is almost the same.
Also, opening/closing the kbd device 5000 times in a small program also
`Rhubarb is no Egyptian god.' Debian http://www.debian.org email@example.com
Marcus Brinkmann GNU http://www.gnu.org firstname.lastname@example.org