AnyEvent::HTTP and Socket on Windows

Ralesk has asked for the wisdom of the Perl Monks concerning the following question:

Fellow Monks,

So, recently, to get around the whole blocking issue with LWP, we’ve switched to using AnyEvent::HTTP instead.

In most cases, this seems to work well, except for one, where seemingly the same call runs into AnyEvent::Socket wanting to mess around with Socket::pack_sockaddr_un, which isn’t implemented under Win32. (Pox on non-POSIX systems)

In particular, I have a module that does the whole HTTP management, and both the broken and the working application call its call() method. Which is nothing spectacular:

sub call {
    my $self = shift;
    my ($method, $path, $format, $query, $content, $cb) = @_;

    $self->{Request} = HTTP::Request->new(
        $method,
        "https://$self->{host}/cgi-bin/api/" . join('/', @$path) . (".
+$format") . ($query ? "?$query" : "")
    );
    $self->{Request}->content($content) if $content;

    $self->_head($self->{Request}, $cb);
}
[download]

(In during a pox on AnyEvent::HTTP for not using HTTP::{Request,Response,Headers} etc.)

_head probes the URI with a HEAD request, gets the nonce, and then does a proper _request with the proper Digest response. And passes over the callback function which was defined during call’s call.

For some reason, one of the apps does this fine (even under Windows), while the other croaks with the above problem. I simply don’t see what could be different between the two.

$api->call(GET => ['foo', $spam],              'json', undef, undef, s
+ub { ... });  ## Program M, works
$api->call(GET => ['bar', $spam, 'baz', $ham], 'json', undef, undef, s
+ub { ... });  ## Program C, doesn't work
[download]

So, no idea at this point.

Comment on AnyEvent::HTTP and Socket on Windows Select or Download Code

Replies are listed 'Best First'.
Re: AnyEvent::HTTP and Socket on Windows by bulk88 (Priest) on Sep 21, 2012 at 20:43 UTC
Random idea, tried using MS's WinHttp with Win32::OLE?	[reply]
Re^2: AnyEvent::HTTP and Socket on Windows by Ralesk (Pilgrim) on Sep 27, 2012 at 06:57 UTC
No, I haven’t. I’d love to avoid such messy workarounds though.	[reply]
Re: AnyEvent::HTTP and Socket on Windows by Anonymous Monk on Sep 27, 2012 at 07:23 UTC
So, no idea at this point About what? You want to patch AnyEvent::Socket... to eval { } any calls to Socket::pack_sockaddr_un?	[reply]
Re^2: AnyEvent::HTTP and Socket on Windows by Ralesk (Pilgrim) on Sep 27, 2012 at 11:49 UTC
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.	[reply] [d/l] [select]
Re^3: AnyEvent::HTTP and Socket on Windows by Ralesk (Pilgrim) on Sep 27, 2012 at 19:09 UTC
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.	[reply]
Re^2: AnyEvent::HTTP and Socket on Windows by Ralesk (Pilgrim) on Sep 27, 2012 at 09:57 UTC
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.	[reply]