R: [Csync2] Write-error while sending data

[Lars Ellenberg]

/ 2006-10-25 12:19:18 +0200
\ Giampaolo Tomassoni:
> > > The expiring alarm seems somehow related to committing an active SQL
> > > transaction, and it seems to happen more or less 2 secs after the file
> > > transfer begins. This means that if you have a fast connection to your
> > > peer you may probably never see this error since either your files
> > > takes less than 2 seconds to tranfer or the write() enters and leaves
> > > the blocking state fast enought to keep low the chance of being
> > > interrupted.
> > 
> > as far as I can see, to set signal handlers in csync2 only
> > signal() is used. this should have BSD semantics and make
> > read() and write() restart themselves if interrupted.
> 
> >From "man 2 signal":
> 
> ...
> 	If  one  on a libc5 system includes <bsd/signal.h> instead of
> 	<signal.h> then signal() is redefined as __bsd_signal and
> 	signal has the BSD semantics. This is not recommended.
> ...
> 
> I can't see any #include <bsd/signal.h>, so I guess that actually BSD
> semantic is not enforced.
> 
> 
> > one could do that explicitly by using sigaction with SA_RESTART instead.
> > that would probably be the correct patch, replacing signal(SIGALRM,...)
> > with sigaction(...) with SA_RESTART set.
> 
> Yes, you're right. But FWIK sigaction() is not available on all *nix
> flavors. So, if we follow this pattern, we must first check this at
> configure() time and eventually even take a solution similar to the
> one I submitted in the fallback case.
> 
> I was submitting a fast-and-dirty patch, not a thought-and-clean one... :)
> 
> 
> > and if it is interrupted by something else but SIGALRM?
> > still retry?  I don't think this is correct.
> 
> The only other trapped signal seems to be SIGPIPE, which is probably
> used in daemon mode by the daemon fork, not by the worker one. Other
> signals do cause basicly csync2 termination, so a further write()
> wouldn't even be called.
> 
> The problem is, however, that this patch protects the write() side of
> the stream while leaving the read() one unprotected. It seems to work,
> however, and I guess that alarm() is not invoked on the slow read()
> side of the link (the receiving one).
> 
> I can provide a sigaction() patch, but I'm feeling a bit unconfortable
> to check for sigaction() availability at configure time...
> 
> Is it ok?

I'm not sure what the intention of the various alarm()s is exactly,
i.e. what exactly they are meant to protect us against.

But I'm happy to commit your patch as is,
as soon as I was able to find time to
verify that it indeed does not break
anything else...

-- 
: Lars Ellenberg                                  Tel +43-1-8178292-0  :
: LINBIT Information Technologies GmbH            Fax +43-1-8178292-82 :
: Schoenbrunner Str. 244, A-1120 Vienna/Europe   http://www.linbit.com :