[PATCH v2] OS/ACPI: Make socket to acpid is non-blocking

[Egbert Eich]

On Thu, Nov 14, 2013 at 01:20:44PM +0900, Keith Packard wrote:
> Egbert Eich <eich at freedesktop.org> writes:
> 
> >  static CARD32
> >  lnxACPICheckTimer(OsTimerPtr timer, CARD32 now, pointer arg)
> >  {
> > +    struct timeval timeval = { 0, 0 };
> >      DebugF("ACPI: trying to reopen\n");
> > -    if (doLnxACPIOpen()) {
> > +    if (doLnxACPIOpen(&timeval)) {
> 
> Does this actually work with a timeout of 0? I'd assume that acpid could
> never accept the connection in time.
> 
> A timeout of 100ms or so seems like it'd be a bunch more reliable?

Yes, you're probably correct. If we can rely on that the listener on 
the other side exists when we get EINPROGRESS it's worthwhile waiting
a bit. Stevens/Rago says: "At this point the connection is complete."
A quick look at the Linux kernel reveals two things:

1. For UNIX sockets the listner does exist when the connect timeout is 
   checked.
2. UNIX sockets never seem to return EINPROGRESS. In the cases where a
   timeout is exceeded, EAGAIN is returned.

Thus the code path in question seems to be irrelevant - at least on 
Linux. My findings however do beg the question, if we shouldn't also
handle the EAGAIN case.

What do you think?

Cheers,
	Egbert.