Hi. I think it would help if you knew what the signal was. Do you have that yet?
I have a report from a user that is is getting EINTR when a SIGALRM goes off on his write(). It isn't unexpected to get SIGALRM because he called the alarm, but he also has SA_RESTART set. I can't remember whose responsibility it is to restart the call, syscall or whereever, but it seems that someone is dropping the ball because if EINTR is returned then SA_RESTART didn't seem to do the trick, right? Thanks, -Cory On 2/25/2011 8:00 AM, Ken Hornstein wrote: >> I don't understand why you don't just fix your application to handle a >> perfectly valid and expected condition (that it's currently not >> handling) instead of wasting time trying to find the cause of the >> expected condition. Even if you find it, it's likely not a bug and not >> something that can/will be fixed. It's your application that needs to >> be fixed. > > To be fair ... normally disk I/O operations are not interruptable by > signals, so it's not an unreasonable behavior on the part of an > application. I did check POSIX, and it doesn't say that behavior is > restricted only to network sockets, so yeah, it's TECHNICALLY allowable > behavior according to the standard (although the Linux manpage for > signal(7) says that it will not happen). But honestly, I've seen > plenty of cases where applications handle this for network I/O; it's > normal, everyone knows it will happen there. But for _disk_ I/O? > Never seen it done. I'm not saying that there are no applications that > handle this case, but it's certainly very uncommon. I freely admit > that network filesystems sort of mix the concepts of "network socket" > and "disk I/O" together, and what is the "right" behavior is unclear. > But calling this perfectly valid and expected is not quite accurate. > It would be interesting to see what other network filesystems do under > the same circumstances. > > --Ken > _______________________________________________ > Lustre-discuss mailing list > [email protected] > http://lists.lustre.org/mailman/listinfo/lustre-discuss _______________________________________________ Lustre-discuss mailing list [email protected] http://lists.lustre.org/mailman/listinfo/lustre-discuss
