Skip Menu |

This queue is for tickets about the IO-Async CPAN distribution.

Report information
The Basics
Id: 101457
Status: open
Priority: 0/
Queue: IO-Async

People
Owner: Nobody in particular
Requestors: TEAM [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Wishlist
Broken in: 0.64
Fixed in: (no value)



Subject: Use accept4 instead of accept by default where available?
Since everything in IO::Async should probably be O_NONBLOCK by default, and sane close-on-exec handling is at least a nice-to-have, any chance of (IO::Async::OS::linux?) using accept4() instead of accept()? http://linux.die.net/man/2/accept4 Might be something that has to be plumbed in at IO::Socket::IP or lower levels, alternatively there's a couple of implementations of accept4() floating around on CPAN if this would be better as a "use it if we have it" feature. (obviously needs SOCK_NONBLOCK | SOCK_CLOEXEC flags to make any difference) cheers, Tom
I'd argue that accept4() should be the syscall that perldoc -f accept uses if available, but getting that past p5p might take longer than the CPAN route! On Sun Jan 11 14:55:23 2015, TEAM wrote: Show quoted text
> > Since everything in IO::Async should probably be O_NONBLOCK by > default, and sane close-on-exec handling is at least a nice-to-have, > any chance of (IO::Async::OS::linux?) using accept4() instead of > accept()? > > http://linux.die.net/man/2/accept4 > > Might be something that has to be plumbed in at IO::Socket::IP or > lower levels, alternatively there's a couple of implementations of > accept4() floating around on CPAN if this would be better as a "use it > if we have it" feature. > > (obviously needs SOCK_NONBLOCK | SOCK_CLOEXEC flags to make any > difference) > > cheers, > > Tom
Getting accept4() into Socket.xs is going to be vastly easier than getting a new core function to wrap it ;) (IMHO longterm a lot of the socket-calling core ops may want to become XS functions in Socket /anyway/, but that's an argument for another day). -- Paul Evans