Hi, On Wed, Jun 02, 2010 at 06:35:02PM +0200, Carl Fredrik Hammar wrote: > On Wed, Jun 02, 2010 at 12:17:12AM +0200, olafbuddenha...@gmx.net > wrote:
> > I'm a bit ambivalent about this... On one hand, returning the right > > error code right away is probably less confusing; but on the other > > hand, it adds extra code paths (with all the associated > > disadvantages) for something that just works in a natural fashion > > right now -- which in a way is actually more elegant... > > I'm mostly concerned with code which want to report the interruption > error. I mean, is it really mandated that interrupted operations > should be retried? Consider a program that doesn't handle any signals > and doesn't otherwise expect an interruption, then it would report the > wrong error. Isn't that normally abstracted by glibc? I.e. only programs invoking the RPC manually would have to do the EINTR check themselfs? BTW I have some recollection that it *is* actually mandated by POSIX that EINTR should always be handled -- though I might be misremembering or confusing something... In either case, it's true that most programs don't observe this, and in fact it would be really painful to do so :-( (This is a generic remark though; I don't think it applies in the situation discussed here.) > Another case this could case confusion is when debugging. Yeah, that's why I suggested documenting it more explicitely... Though indeed it might still be confusing. As I said, I'm ambivalent about this. > In fact, I recently suffered such confusion in a similar case where I > accidentally sent a null port to auth, which resulted in EINTR. At > first I thought that gdb was somehow interfering with some sort of > signal handling. (It wouldn't have been the first time gdb and signals > mess things up for me.) > > This also tells me that we should be testing for null ports as well. > Though this only needs to be done in the beginning of the function > since there is no risk of a port becoming null. Actually, since > there's currently no testing at all you'll loop indefinitely if you > restart! I don't fully understand the situation -- but this sounds like something that should be catched early, so it doesn't even enter the RPC interruption code path... -antrik-
