Not neccessarily. Its dependant on the signal properties they used. If
they just used signal() then its system dependant and Linux like 4BSD
will restart the recvfrom. Use sigaction if you need to force behaviour
portably
-
To unsubscribe from this list: send the line "unsubscribe linux-smp" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
This was a traditional client - multiple-servers distribted
programming assignment. Students could use TCP/IP to connect the
client to N servers, or they could use UDP if they wanted. One
student wanted to try the broadcast facility to discover where the
servers were.
His approach was to do a broadcast, then use alarm() to set a time-out
interval, then use an infinite loop to recvfrom() the responses to the
broadcast. When the alarm signal arrives, the recvfrom() should be
interrupted with an EINTR error condition which he wanted to use to
terminate the recvfrom() loop. On Solaris it worked perfectly. But
when he tried it on his linux box at home, it hung. We discovered
that recvfrom() is not getting interrupted as it should, although
other system calls seem to work just fine and get interrupted as they
should. He changed his code to use a select on that single socket,
and it works fine on linux as select() does get interrupted properly.
It is obviously a bug, The question is, where? In the glibc stuff
or in the kernel itself? I am running 2.4.18 everywhere. I suspect
he was running something different, although it failed on both.
Suggestions on who to contact with a bug report?
--
Robert Hyatt Computer and Information Sciences
hy...@cis.uab.edu University of Alabama at Birmingham
(205) 934-2213 115A Campbell Hall, UAB Station
(205) 934-5473 FAX Birmingham, AL 35294-1170