accept/signal/EINTR

[Martin Horcicka]

Pav Lucistnik (2004-09-01 12:58 +0200):

> 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?
>
> EINTR je neco jineho, to je syscall preruseny interruptem, za
> predpokladu ze syscall neni restartable.

Myslim, ze nemas pravdu - sigaction(2):

      If a signal is caught during the system calls listed below, the call may
      be forced to terminate with the error EINTR, the call may return with a
      data transfer shorter than requested, or the call may be restarted.
      Restart of pending calls is requested by setting the SA_RESTART bit in
      sa_flags.  The affected system calls include open(2), read(2), write(2),
      sendto(2), recvfrom(2), sendmsg(2) and recvmsg(2) on a communications
      channel or a slow device (such as a terminal, but not a regular file) and
      during a wait(2) or ioctl(2).  However, calls that have already committed
      are not restarted, but instead return a partial success (for example, a
      short read count).

Zrejme to je proste pro ruzna volani jadra ruzne a nekonzistence informaci o 
accept je jen neporadek.

Martin