Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 03 Jan 2008 11:45:04 -0800
From:      Garrett Cooper <youshi10@u.washington.edu>
To:        Metin KAYA <metin@EnderUNIX.org>
Cc:        freebsd-hackers@freebsd.org, "Rick C. Petty" <rick-freebsd@kiwi-computer.com>
Subject:   Re: select
Message-ID:  <477D3B40.9020805@u.washington.edu>
In-Reply-To: <477D3977.3030608@u.washington.edu>
References:  <1571995824.20080103205248@EnderUNIX.org>	<20080103192245.GB90170@keira.kiwi-computer.com>	<363446479.20080103213223@EnderUNIX.org> <477D3977.3030608@u.washington.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
Garrett Cooper wrote:
> Metin KAYA wrote:
>>    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?
>>
>>  
>>> On Thu, Jan 03, 2008 at 08:52:48PM +0200, Metin KAYA wrote:
>>>    
>>>>   How select(2) will behave if I give the "utimeout" parameter as
>>>>   NULL?
>>>>       
>>
>>  
>>> According to the man page:
>>>     
>>
>>  
>>>      If timeout is not a null pointer, it specifies the maximum 
>>> interval to
>>>      wait for the selection to complete.  System activity can 
>>> lengthen the
>>>      interval by an indeterminate amount.
>>>     
>>
>>  
>>>      If timeout is a null pointer, the select blocks indefinitely.
>>>     
>>
>>  
>>>      To effect a poll, the timeout argument should not be a null 
>>> pointer, but
>>>      it should point to a zero-valued timeval structure.
>>>     
>>
>>
>>  
>>> -- Rick C. Petty
>>>     
>>
>>
>> --                          Metin KAYA                  EnderUNIX 
>> Software Developer          Endersys Software Engineer
>> http://www.EnderUNIX.org/metin        http://www.Endersys.com/
>>   
> Nevermind -- yes, block indefinitely, which implies that the program 
> won't proceed until it receives an umasked signal and exits or a file 
> descriptor becomes available in the 'infinite' time frame.
>
> That would essentially be the same as listen or send though with 
> blocking sockets, correct?
>
> -Garrett
Well, the waiting part at least, not the sending and receiving part of 
send and listen, respectively..
-Garrett



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?477D3B40.9020805>