in reply to Calling strace -f
in thread Diagnosing blocking io (or: finding the WHY of my Open2 woes).

read(0, "load(\'jslint.js\');\nfoo=0;\nEND\n", 1024) = 30 read(0, "", 1024) = 0 read(0, "", 1024) = 0 close(0) = 0 <-- !!! munmap(0xb7b8a000, 4096) = 0 brk(0x8092000) = 0x8092000 open("jslint.js", O_RDONLY) = 0

I think the problem is this close(0). Because of it, the file descriptor is being reused in the subsequent open("jslint.js" (as the lowest available file descriptor) when the js interpreter is reading in the jslint.js file, at the end of which it gets closed again... Anyhow, the net effect of this is that stdin (which is expected to be connected to the pipe) is no longer open when your line=readline() is trying to read from it. Thus the readline is failing, and the while (true) {...} keeps looping forever...

Note that when being run interactively, the jslint.js file is read in via a different file descriptor, and stdin (file descriptor 0) can still be read from afterwards.

I'd suspect the undesirable close(0) has to do with you closing the other end of the pipe ($JSWRITE) before the js interpreter starts executing the load('jslint.js'); command you sent it.  So that's where I would start fiddling... (if I really wanted to know :)

Replies are listed 'Best First'.
Re^2: Calling strace -f
by Socrates (Acolyte) on Nov 19, 2008 at 22:17 UTC
    I tried commenting out that line, and I get:
    ... ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbf99e438) = -1 EINVAL (Inval +id argument) fstat64(0, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, + 0) = 0xb7b62000 read(0, "load(\'jslint.js\');\nfoo=0;\nEND\nqu"..., 1024) = 38 read(0,

    So, it's not even to the point where it's processing the information coming from perl. It hasn't even loaded jslint.js yet. I think I get it. So let's see if I'm understanding this properly:

    While perl may be properly autoflushing, the interpreter is still buffering its read. Since the socket(?) is still open, it doesn't know to close it and flush.

    When it does close it and flush, it is acutally waiting to make use of the rest of the string ("foo=0;\nEND\n") AFTER the readline loop. So it would be as if I had done something like this (which also freezes):

    $ echo -e "load('jslint.js');\nfoo=0;\nEND\n" |/usr/bin/js

    Hence, the rock and hard place are that, if I don't close $JSWRITE in a timely manner, the interpreter won't know to flush its read buffer and continue, but if I do close $JSWRITE, there's nothing for the readline() loop to read from anymore.

    So it's not so much that my Perl code isn't outputting correctly, it's that the interpreter is accepting/buffering input in an incompatible way?

      if I don't close $JSWRITE in a timely manner, the interpreter won't know to flush its read buffer and continue, but if I do close $JSWRITE, there's nothing for the readline() loop to read from anymore.

      I think you nailed it.

      Update: Ignore this post. I misunderstood the issue

      Buy why is it calling close(0)? And why is it different when it's connected to a terminal? SIGPIPE?

      I see three possible solutions:

      • Fooling it into thinking its talking to a terminal.
      • Sending "\n"x4096 after "END".
      • Maing js read from a file, not from a pipe.

      So the solution is to not read from STDIN. Pass a file name instead of the file contents.

      my $js_script_qfn = to_js_str_literal($script_qfn); print $JSWRITE <<"__END__"; var filename = $js_script_qfn; load('jslint.js'); END __END__

      Well, don't know if scoping allows that exactly, but you get the idea.

      Update: I suppose you could pass the file contents in the same manner.

      print $JSWRITE map "$_\n", "var file = [", ( map " ".to_js_str_literal($_), <$fh> ), "];", "load('jslint.js');", "END";