AnyEvent and Strawberry perl issue

[Marc Lehmann]

On Sun, Mar 15, 2015 at 02:33:46AM +0100, Christian Walde <walde.christian at gmail.com> wrote:
> I'd rather not involve myself with this, but it was suggested to me
> that dropping the relevant bits of information on the mailing list
> explicitly would be a good idea.

Sounds like a good idea, this doesn't seem to be common knowledge among
p5pers.

> WSAEINPROGRESS equal. I am unclear exactly how the equality mapping is
> brought about and what kind of real world effects this can have.

As for real-world effects, a program getting EINPROGRESS and then waiting
for the final results of the operation will wait forever on windows now,
as WSAEINVAL means the operation that was attempted will not be done.

As such, WSAEINPROGRESS most closely matches POSIX EALREADY in (paper)
semantics, but is issued in other circumstances.

As for the mapping, I am not sure this is an answer to your question, but
perl apparently maps _every_ WSAExxx code to the Exxx code of the same name,
regardless of the operation, as long as the Exxx code is available.

This seems to be done in "convert_wsa_error_to_errno", and the comment for
this function indicates that the rationale was indeed as simple as "if
defined WSAExxx and defined Exxx then map WSAExxx to Exxx", with the
assumption that similar name implies same behaviour).

> Now, i have never used any of this, and do not know the details of the
> systems behind it, so i can only read the words as offered and interpret
> them naively.

To know the details, I am afraid one would have to study the winsocket
source code (which is complicated by the fact that there are many
different implementations).

The practical difference seems to be that EINPROGRESS in POSIX means that the
operation the program tried is in progress.

While in winsockets, there seems to be a check whether there is another
operation already in progress, in which case the attempted operation is
aborted with WSAEINPROGRESS.

This is not the whole truth, though, as WSAEINPROGRESS seems to be issued
under some other circumstances as well.

In all cases, though, WSAEINPROGRESS is a real error, while in POSIX, it
is a status indication similar to EAGAIN.

> To my amateur naive reading these two are not simply slightly different,
> but seem to describe wildly different situations.

... something which can be established in practice is well.

> So the obvious question is: Did i misread?

I think not - but both POSIX errno descriptions and MSDN documentation are of
course pretty vague, as many error codes have specific meaning for specific
calls, so the real test is the actual system behaviour.

> Are there non-obvious details that make it okay?

That depends on the definition of okay, that is, for a program that handles
EINPROGRESS after connect it is absolutely wrong, but for programs that might
not care about the actual errno value, it might be ok.

For example, a program handling EINPROGRESS after sysread() will probably
report an error, and this change wouldn't affect this. But for the much
more common case of connect + EINPROGRESS, it would simply be wrong.

I think what is important to keep in mind is that most winsocket error
codes do not map well on POSIX error codes. Some of them strikingly bad
(such as WSAEINPROGRESS), some of them with considerable overlap.

It is, however, a case-by-case thing, so perl blindly mapping all WSAE codes
to E codes is simply wrong.

> On exactly what basis was the decision made that these two can be equivalent?

Nobody seems to want to answer that, or to be able to answer that, but
evidence is pretty strong that the basis was simply the string match between
the symbol names.

I think a case-by-case reasoning can be excluded with high probability
because it would be pretty unlikely that all these codes would pass a more
involved test (EINPROGRESS and EINVAL certainly shouldn't).

> God damn, way too many words.

True, for something that should be a simple "oops, this needs to be
fixed", as with so many things that are being light-heartedly broken in
perl without ever getting fixed.

My thanks for your constructive contribution, which proves a reaction other
than bringing up a whole lot of derailing strawmen is possible.

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\