Re: [PATCH] Check for rendezvous port death in auth server

[olafBuddenhagen]

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, olafBuddenhagen@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-