[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Carl Fredrik Hammar
Subject: Re: [PATCH] Check for rendezvous port death in auth server
Date: Wed, 2 Jun 2010 18:35:02 +0200
User-agent: Mutt/1.5.20 (2009-06-14)


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.

Another case this could case confusion is when debugging.  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!

> Perhaps just add comments in appropriate places (the actual code
> returning the errors, and the RPC definitions) documenting the current
> behaviour?

To me, mandating that all clients should restart in all cases (if it's
not already so) seems more complicated than just returning the error code.
But sure, that'd work too.

> (Sorry for not bringing it up earlier; it only became clear in my mind
> when I saw the actual code...)

No problem, actual code always clears things up.  :-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]