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

[Egbert Eich]

On Fri, Nov 15, 2013 at 11:25:49AM +0100, Egbert Eich wrote:
> 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?

It seems irrelevant, but I'd give it 30ms as in the lnxACPIOpen() case.

> 
> 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?

In fact we do already. I'm still going to update the patch to improve the 
errno mess a bit.

Cheers,
	Egbert.