The particularly funny part was that AnyEvent::Socket does have that Socket::pack_sockaddr_un call in eval.

So I patched it:

--- Socket.pm   2012-09-27 13:27:38.856750000 +0200
+++ Socket.pm.win32     2012-09-27 13:28:45.466125000 +0200
@@ -579,7 +579,7 @@ module (C<format_address> converts it to
 # sockaddr_un structures of maximum length (which is not, AFAICS, req
+uired
 # by any standard). try to 0-pad structures for the benefit of those 
+platforms.

-my $sa_un_zero = eval { Socket::pack_sockaddr_un "" }; $sa_un_zero ^=
+ $sa_un_zero;
+my $sa_un_zero = eval { Socket::pack_sockaddr_un "" } unless AnyEvent
+::WIN32; $sa_un_zero ^= $sa_un_zero;

 sub unpack_sockaddr($) {
    my $af = sockaddr_family $_[0];
[download]

But actually, it wasn’t AnyEvent::Socket’s fault. One of the programs has a $SIG{__DIE__} override, while the other doesn’t; for debugging purposes (provides a nice-ish traceback) — and this broke the eval { } in AnyEvent::Socket.

Though, it doesn’t make sense to even attempt to run that function under Win32, so the patch isn’t really without sense.

And mlehmann said that if we’re doing what we’re doing, we’re most certainly breaking other things too that use exceptions, so we should really go fix the die handler.

For the record: taking into account $^S, using an END { } block and CORE::GLOBAL::die overriding are better.

Mostly curious if anyone’s run into this issue (that this stack of tools wants to run that function on Windows sometimes), and if so, whether they figured out what causes it.

From what I see, the two programs are doing this async communication identically (only differing in the actual RPC call, but it’s done to the same server), both are Glib loops (if that matters), and so on. They shouldn’t be doing things any differently.