R: [Csync2] Write-error while sending data

[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?

-----------------------------------
Giampaolo Tomassoni - IT Consultant
Piazza VIII Aprile 1948, 4
I-53044 Chiusi (SI) - Italy
Ph: +39-0578-21100

MAI inviare una e-mail a:
NEVER send an e-mail to:
 rainbowl at tomassoni.eu


> 
> -- 
> : Lars Ellenberg                                  Tel +43-1-8178292-55 :
> : LINBIT Information Technologies GmbH            Fax +43-1-8178292-82 :
> : Schoenbrunner Str. 244, A-1120 Vienna/Europe   http://www.linbit.com :
> _______________________________________________
> Csync2 mailing list
> Csync2 at lists.linbit.com
> http://lists.linbit.com/mailman/listinfo/csync2