[Libevent-users] SO_LINGER option for sockets created by evhttp

[Scott Lamb]

Marc Lehmann wrote:
> On Fri, Dec 14, 2007 at 12:56:00PM -0800, Scott Lamb <slamb at slamb.org> wrote:
>> Tests and results here:
>>
>> http://www.slamb.org/svn/repos/trunk/projects/socket_tests/index.html
> 
> "The UNIX socket API has been standardized for a decade. But the standards
> are vague on a lot of critical behavior."
> 
> In defendence of the standards (in this case the single unix spec.),
> the blocking behaviour is _mandated_ by the SUS, and not following this
> behaviour is a bug if the platform claims to follow unix behaviour. Of
> course, OS X is quite far from any unix behaviour, so the portability
> problem remains.
> 
> The problems are, however, far fewer in number if one only tests unix
> platforms, which also have problematic behaviours but overall perform much
> better than the unix emulation in os x.

I'm not going to get into stupid hairsplitting about what "unix 
emulation" vs "unix platforms" means, but OS X's networking code was 
largely inherited from FreeBSD. I would expect older FreeBSD systems to 
have the same behavior.

> However, that page has a lot of problems, for example it requires
> non-standard behaviour and declares standard behaviour as "failure", an
> example would be:
> 
>    read(0) while connecting
> 
>    EWOULDBLOCK failure (linux)
>    0           failure (os x)
> 
> EWOULDBLOCK is not a standard error code, the standard only documents EAGAIN
> (which is what linux actually returns). The test expects EINPROGRESS, but
> that is not allowed by the unix standard, so a platform actually getting a
> green status there would be _broken_.

EWOULDBLOCK is how the Python library reported the error. On Linux, 
EWOULDBLOCK and EAGAIN are synonymous.

> 
> Also, returning 0 is also allowed in this case, so the os x test is also
> errornously marked as failing, when, in fact, it is fully standards
> compliant.
> 
> So while the raw results of that page are very interesting, it would be
> more useful if the interpretation as failure or not would not _require_
> behaviour that is wrong by de-facto and actual standards.
> 

I chose "failure" vs. "success" criteria rather arbitrarily - especially 
in the cases where I couldn't find a clear answer in the standard, they 
  were basically just "was it the same as the first platform I tried 
that test on". I should probably remove the color coding.

If you take a more thorough look at the page, you'll see a note to that 
effect.