Net::HTTP::NB blocks on connect()

[FGasper]

Saw this in an strace:

socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3<TCP:[4870277]>
ioctl(3<TCP:[4870277]>, TCGETS, 0x7ea8924c) = -1 ENOTTY (Inappropriate ioctl for
 device)
_llseek(3<TCP:[4870277]>, 0, 0x7ea892a8, SEEK_CUR) = -1 ESPIPE (Illegal seek)
ioctl(3<TCP:[4870277]>, TCGETS, 0x7ea8924c) = -1 ENOTTY (Inappropriate ioctl for
 device)
_llseek(3<TCP:[4870277]>, 0, 0x7ea892a8, SEEK_CUR) = -1 ESPIPE (Illegal seek)
fcntl64(3<TCP:[4870277]>, F_SETFD, FD_CLOEXEC) = 0
connect(3<TCP:[4870277]>, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_
addr("208.74.123.84")}, 16) = 0

This comes from just calling:

my $s = Net::HTTP::NB->new(
    Host => 'cpanel.net',
    Blocking => 0,
) or die;

Is this a bug, or a known part of the design? Is there any way to get a non-blocking connect()?

[skaji]

You may multiplex sockets for reading with Net::HTTP::NB, but not for dns lookup, connecting or writing.

[FGasper]

Would you be amenable to considering a patch to make it non-blocking for connections, at least?

[skaji]

LWP is a blocking HTTP client, and Net::HTTP exists solely for it.
So I'm not sure it is worth adding additional asynchronous features to it.

[FGasper]

LWP is a blocking HTTP client, and Net::HTTP exists solely for it.

Net::HTTP’s documentation doesn’t say it’s specifically for LWP; in fact, the only mention of LWP at all is in the SEE ALSO section. 20+ CPAN distributions depend on Net::HTTP. On what basis, then, do you assert that the only supported caller is LWP?

If this is indeed the case, though, should NB.pm be deprecated, and Net::HTTP’s documentation updated to disavow support for any caller other than LWP?