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