This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
I'd go without the abort in this case -- primarily because glibc hasn't introduced aborts for this kind of "can't or shouldn't happen" behaviour as liberally as other projects (such as GCC). I'm not aware of any in the hand written assembly bits, which were written presumably to be absolutely as fast as possible.I would be surprised if a single branch after a syscall would be a measurable performance degradation. Not sure what the policy for this is, but I'd prefer an abort or such if we get a return value we didn't expect. Also, if we get frequent spurious wake-ups, then this branch is the smallest part of the overhead.
I got the impression in the past that the nptl code had to be as trim as possible, which is why I left it out on purpose. If the abort is OK in this for others, I'll put it in.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |