accept/signal/EINTR

Jan Pechanec jp at devnull.cz
Wed Sep 1 13:16:38 CEST 2004


On Wed, 1 Sep 2004, Pav Lucistnik wrote:

>V st, 01. 09. 2004 v 12:13, Jan Pechanec píše:
>
>> 	ahoj, resil jste nekdo, ze accept(2) neni prerusitelny 
>> signalem (jde mi pochopitelne o alarm)? Plati pro 
>> 4.10/5.2.1/5.3-BETA1. Mohu si samozrejme poradit jinak, ale rad bych 
>> vedel ten duvod. Ruzne zdroje totiz uvadi ruzne informace (jde 
>> to/nejde to/ma to jit) a 'man accept' rika jen to, ze volani muze 
>> vratit EINTR v pripade, ze "The accept() operation was interrupted". 
>> Rychlym pohledem do zdrojaku tohoto volani se mi to ale nezda.
>
>To je bezna situace ze signaly jsou doruceny procesu az po navratu ze
>syscallu, ne?

	ano a ne. Tak to bylo rozhodne driv, ale nektery syscally jdou 
signalem prerusit.

>
>EINTR je neco jineho, to je syscall preruseny interruptem, za

     4 EINTR Interrupted system call.  An asynchronous signal (such as SIGINT
             or SIGQUIT) was caught by the process during the execution of an
             interruptible function.  If the signal handler performs a normal
             return, the interrupted system call will seem to have returned
             the error condition.

	
>predpokladu ze syscall neni restartable.

	napr. z man select(2):

     [EINTR]            A signal was delivered before the time limit expired
                        and before any of the selected events occurred.

	a zde to funguje i na alarm a myslim, ze i na ostatni signaly.

	Ja bych se tim ani nezabyval a bral bych to, ze v acceptu to 
proste nejde, kdyby nenasel ruzny web zdroje, kde popisuji na prikladu 
acceptu, ze to jde. Pravda, typicky bez udani konkretniho OSu.

	h.


-- 
Jan Pechanec <jp (at) devnull (dot) cz>


More information about the Users-l mailing list