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?
MIME-Version: 1.0
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
Message-ID: <rt-4.0.18-514-1420988123-823.0-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 564
Download (untitled) / with headers
text/plain 564b
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
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-514-1420988123-823.0-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-4.0.18-514-1420988123-823.0-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-15066-1420988252-399.101457-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 800
Download (untitled) / with headers
text/plain 800b
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
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-15066-1420988252-399.101457-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-4.0.18-514-1420988123-823.0-0-0 [...] rt.cpan.org> <rt-4.0.18-15066-1420988252-399.101457-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-528-1420994094-841.101457-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 271
Download (untitled) / with headers
text/plain 271b
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


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.