Date: Tue, 2 Aug 2011 23:45:11 +0200 From: Vlad Galu <dudu@dudu.ro> To: Jilles Tjoelker <jilles@stack.nl> Cc: hackers@freebsd.org Subject: Re: eliminating a syscall on accept()+ioctl() combo Message-ID: <B54283C7-B8E9-47DB-9590-47F5DE016C50@dudu.ro> In-Reply-To: <20110802211652.GA28731@stack.nl> References: <E27242EA-A2DD-4CB8-92B6-8B95B3BF3B8E@bitpowder.com> <7E99FCF5-66DF-422E-B2FE-28547AF916A7@dudu.ro> <20110802211652.GA28731@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Aug 2, 2011, at 11:16 PM, Jilles Tjoelker wrote: > On Mon, Aug 01, 2011 at 08:11:04AM +0200, Vlad Galu wrote: >> On Jul 31, 2011, at 9:59 PM, Bernard van Gastel wrote: >>> I want to reduce the number of syscalls for my networking >>> application. The app handles incoming connections with the >>> 'accept()' system call. Is there a way to specify to accept() that >>> the newly created file descriptors should be non-blocking (FIONBIO)? >>> This will avoid an ioctl() after the accept(). Thanks! > >> You can make your listening socket non-blocking. Newly created file >> descriptors will inherit that property. However, that will require you >> to select()/poll()/kqueue() for that descriptor as well, instead of >> simply blocking in accept(). > > This is documented FreeBSD behaviour and common across BSDs, but is not > portable. POSIX leaves it unspecified what the non-blocking state of the > new socket is and in fact Linux always makes the new socket blocking > (unless you request non-blocking using their new accept4() call). > > Because this portability issue can be very subtle, I suggest not blindly > relying on it. Oh, ok. I wasn't aware. Thanks for the heads-up. Good, fast & cheap: pick any two.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B54283C7-B8E9-47DB-9590-47F5DE016C50>