[darcs-users] push --and-apply

[Aggelos Economopoulos]

On Tuesday 16 September 2003 16:26, David Roundy wrote:
> On Tue, Sep 16, 2003 at 05:21:57AM +0300, Aggelos Economopoulos wrote:

[...]

> > Any clues?
>
> Yuck.  I also ran into this problem when testing the curl (as opposed to
> libcurl) version.  I don't properly understand it, and so I came up with a
> very crude hack for copyRemoteCmd, which was to retry every time I failed
> due to a SIGVTALARM interrupt.  This worked because the error was only
> sporadic.  It may also be sporadic in the scp case, I just don't know.
>
> As I understand it (and I don't very well), the virtual timer is an
> interrupt timer that gets called when a certain amount of CPU time is used
> by a process.  When it is called, the process dies, and that is what is
> happening.  What I don't know is why the timer is getting set in the first
> place.  My only guess is that for some reason execvp is setting the timer.
> Either that or it is getting set when I fork.

After grepping a while in a ghc5 source tree, it seems neither is true. The 
timer seems to be set for the program irrespective of the fork/exec syscalls. 
The runtime appears to use it (the timer) for profiling itself (which is one 
obvious usage of setitimer()/getitimer()) - see ghc-5/ghc/rts/Itimer.c . 
Obviously the signal handlers are thrown away during the exec, so the new 
process gets an unexpected SIGVTALRM and dies.

Unless I'm missing something, we are talking about a ghc bug. ghc has a 
pPrPr_disableITimers function which it calls e.g. in executeFile, but some 
paths leading to execve(2) are probably left unprotected. Copying 
pPrPr_disableITimers from ghc (which does no error checking and unnecessarily 
clears .it_interval) and calling it from read_ssh should work (if I'm right).

Does this sound logical?

Aggelos