Weird bug when mixing futures and redirection

[EliasC]

The following program runs and prints Done! as expected:

class Foo
  def foo() : void
    ()

class Main
  def main() : void
    let x = new Foo in{
      get x.foo();
      print "Done!";
    }

bash-3.2$ ./foo
Done!
bash-3.2$

However, if we redirect stdout somewhere, the output disappears:

bash-3.2$ ./foo | xargs echo
bash-3.2$ 

bash-3.2$ ./foo > foo.txt
bash-3.2$ cat foo.txt
bash-3.2$ 

The problem only arises when redirecting stdout:

bash-3.2$ ./foo 2> foo.txt
Done!
bash-3.2$ cat foo.txt
bash-3.2$ 

The problem goes away if we get rid of the futures:

passive class Foo
  def foo() : void
    ()

class Main
  def main() : void
    let x = new Foo in{
      x.foo();
      print "Done!";
    }

bash-3.2$ ./foo | xargs echo
Done!
bash-3.2$ 

It also goes away if we add an embedded fflush to the end of the main method:

class Foo
  def foo() : void
    ()

class Main
  def main() : void
    let x = new Foo in{
      get x.foo();
      print "Done!";
      embed void
        fflush(NULL);
      end
    }

bash-3.2$ ./foo | xargs echo
Done!
bash-3.2$ 

It seems like some buffer for stdout is not flushed when the actor performing the print is suspended, waiting for the future to be fulfilled. Flushing in the end of the main function in the generated C-code (i.e. right before returning from int main()) does not fix the problem, so probably some other thread(s) needs to flush it. I'm not going to spend any more time on this until the new futures arrive.

[sophiaIC]

That could the title of a song! ☺

[EliasC]

@sophiaIC Please send me a playlist with the kind of music where "Weird bug when mixing futures and redirection" is a normal song title :)

[sophiaIC]

until the new futures arrive.
I will, as soon as the new futures arrive.

[albertnetymk]

Is it still the case with the HEAD of master, 79f29b2?

[EliasC]

This no longer seems to be an issue! I'll close this.

[supercooldave]

Is there a test case to prove that this is no longer an issue?

[EliasC]

@supercooldave The two tests touched by the related commit (345f43b) were the ones that needed the workaround. Since we don't know what was causing the issue before, it's hard to write a test that for it, but at least they both work (as well as the example above).

[supercooldave]

Good enough.