>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
