AnyEvent and Strawberry perl issue

[Marc Lehmann]

On Sun, Mar 15, 2015 at 04:21:48PM +0000, Steve Hay <steve.m.hay at googlemail.com> wrote:
> light), but it's interesting to note that perl is far from alone in

It is indeed interesting, but in my experience, most code is extremely
broken, and works in 99.5% of the cases at best.

And many people would not consider this as extremely broken.

Similarly, most code doesn't even attempt to fix corner cases, and thus
only works on win32 for some limited testcases, and subtly fails in the
real world. Breakage in uncommon cases often takes years to surface.

And the EINPROGRESS thing cannot be the full story, as I found out about
EINPROGRESS behaviour by actively testing with a win32 perl (activate 5.10
if I remember), and the code did work there.

tcl/tk for years didn't support more than 32 file descriptors on 64 bit
platforms, and perltk took much longer to keep up. Nobody seems to have
realised.

Event::Lib crashes so easily that I couldn't come up with a stable
backend, yet it is an interface to the very often used libevent
library. Nobody bothers. Perhaps even code exists that uses it and works.

Most users do not create their own conenctions, but use these facilities
through a relatively small number of libraries, and breakage in uncommon
cases can take years to surface.

This you end up with horrible workarounds for perl as seen in IO::Socket.

I think this just emphasizes that the widespread breakage of many popular
such libraries every year is unacceptable, but perl5porters already
rejected backwards compatibility as a goal (despite continuing to document
it), so debating this is moot.

> source tarballs for four other popular scripting languages (Python,
> Ruby, Tcl and PHP) to see what they do, and they all make the same
> mistake as perl in mapping whole lists of Exxx / WSAExxx constants
> with similar names, including EWOULDBLOCK and EINPROGRESS:

As a more humorous remark: Sometimes I can't suppress the thought
that AnyEvent is the only event library that actually tries to get it
right - seriously, this level of attention is very rare (for example,
reading errors via error slippage in getpeername and read), so it is not
surprising that many programs seem to work. And especially on win32,
who is surprised if programs sometimes hang or have spurious connection
errors.

All in all, this should just teach you how easy it is to create bugs that are
very hard to track down, often never get tracked down for years, and that
reckless behaviour is very damaging.

Reckless behaviour such as using an error code that is virtually unused
outside of win32 perl (EWOULDBLOCK). No matter how much you argue that
this behaviour is allowed by POSIX, windows isn't POSIX, perl isn't POSIX,
and this just asks for trouble for no gain whatsoever.

Not to mention that now win32 perl is the *only* platform which requires
an EWOULDBLOCK check, a check that I deliberately didn't implement after
researching all platforms I cared for (including win32 perl).

True to the motto: "Perl - makes even your program slower and more
complicated, just because we can".

(I just realised that this sarcasm was a bannable offense on this list. Or
was it legal irony? Or is the code of conduct it only applied when ricardo
thinks it should be applied?).

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