I have done some debugging and for me its the send method that hangs ( Statistics::R::Bridge::pipe), in particular this loop

    my ($x,$xx) ;
    while( (!$has_quit || $this->{STOPING} == 1) && -e $file && $this-
+>is_started( !$this->{STOPING} ) ) {
      ++$x ;
      ##print "sleep $file\n" ;
      select(undef,undef,undef,$delay) ;
      if ( $x == 20 ) {
        my (undef , $data) = $this->read_processR ;
        if ( $data =~ /\s$n\s+\.\.\.\s+\// ) { last ;}
        $x = 0 ;
        ++$xx ;
        $delay = 0.5 ;
      }
      if ( $xx > 5 ) { $status = undef ;} ## xx > 5 = x > 50
    }
[download]

Its because $n/$data don't match ($n ends up being 1, but $data contains a high number, the last number written to process.log).

$n/$data are populated by read_processR, which reads process.log, which is written to by rterm.exe, as per instructions in start.r (PERLOUTPUTFILE), which is written from sub Statistics::R::Bridge::pipe::save_file_startR.

What happens is that at the beginning of send, where $n is set, read_processR reads data ending with "/", so $n defaults to 1.

mokleva was right, it is some kind of race condition. Whether its rterm that misbehaves, or start.r or Statistics::R that make an assumption ... I don't know. Thats as far as I'm willing to go, but it should be enough information for someone familiar with rterm/statistics-r to fix it.

BTW, my enviroment is perl v5.8.4 ActivePerl Build 810, R 2.2.1, WinXP Home.