Date: Thu, 03 Jan 2008 20:53:22 +0100 From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no> To: Metin KAYA <metin@EnderUNIX.org> Cc: freebsd-hackers@freebsd.org, "Rick C. Petty" <rick-freebsd@kiwi-computer.com> Subject: Re: select Message-ID: <86prwid6tp.fsf@ds4.des.no> In-Reply-To: <363446479.20080103213223@EnderUNIX.org> (Metin KAYA's message of "Thu\, 3 Jan 2008 21\:32\:23 %2B0200") References: <1571995824.20080103205248@EnderUNIX.org> <20080103192245.GB90170@keira.kiwi-computer.com> <363446479.20080103213223@EnderUNIX.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Metin KAYA <metin@EnderUNIX.org> writes:
> Yes Rick, I'm asking this "indefinitely" issue. Is there anything that
> handle this NULL situation a signal, or etc.? How does Linux or
> FreeBSD behave?
Please don't top-post.
Like most other system calls that block "indefinitely", select(2) will
be interrupted by signals. This is *also* documented in the man page
you didn't read:
[EINTR] A signal was delivered before the time limit expired
and before any of the selected events occurred.
See sigaction(2) for details on how to modify the way system calls
behave when a signal is delivered.
DES
--=20
Dag-Erling Sm=C3=B8rgrav - des@des.no
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86prwid6tp.fsf>