[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MS-Windows build broken in Fmake_network_process

From: YAMAMOTO Mitsuharu
Subject: Re: MS-Windows build broken in Fmake_network_process
Date: Sat, 27 Mar 2010 09:51:56 +0900
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shijō) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI)

>>>>> On Fri, 26 Mar 2010 18:22:36 +0300, Eli Zaretskii <address@hidden> said:

> This change:
>     revno: 99750
>     author: Helmut Eller <address@hidden>
>     committer: YAMAMOTO Mitsuharu <address@hidden>
>     branch nick: trunk
>     timestamp: Thu 2010-03-25 17:48:52 +0900
>     message:
>       Call `select' for interrupted `connect' rather than creating new socket 
> (Bug#5173).

> breaks the MS-Windows build:


> The linker error is because we would need to link against yet another
> library to get this function.  But I don't think we should do that.
> I'm actually bewildered why this code:

>           int len = sizeof xerrno;
>           eassert (FD_ISSET (s, &fdset));
>           if (getsockopt (s, SOL_SOCKET, SO_ERROR, &xerrno, &len) == -1)
>             report_file_error ("getsockopt failed", Qnil);

> was used unconditionally when a very similar code in
> wait_reading_process_output is clearly marked with a comment saying
> not to use it except on GNU/Linux:

>   #ifdef GNU_LINUX
>               /* getsockopt(,,SO_ERROR,,) is said to hang on some systems.
>                  So only use it on systems where it is known to work.  */
>               {
>                 int xlen = sizeof(xerrno);
>                 if (getsockopt(channel, SOL_SOCKET, SO_ERROR, &xerrno, &xlen))
>                   xerrno = errno;
>               }
>   #else

Actually I was aware of the above part when I committed the change in
question.  But the code above was added in 2002, and I doubted whether
it is still the case for the systems that are supported by Emacs
24.0.50.  So I didn't copy the above code for Fmake_network_process.

Can normal (i.e., blocking) `connect' in Windows be interrupted by a
POSIX signal counterpart?  If not, then we can disable the whole added
code for Windows in the first place.

                                     YAMAMOTO Mitsuharu

reply via email to

[Prev in Thread] Current Thread [Next in Thread]