Why does nodejs hand down a socket instead of a character device when exec is being called?

[FabianFrank]

When using a simple snippet to execute a command with nodejs, such as

var sys = require('sys')
var exec = require('child_process').exec;
function puts(error, stdout, stderr) { sys.puts(stdout) }
exec("./stdout_type", puts);

The stdin and stdout that are given to the process are not character devices, but sockets. For example ruby, perl and other languages hand down a character device. Full experiment:
https://github.com/FabianFrank/node-exec-socket

It seems that generally this is not problematic. However, today I stumbled upon the following piece of code in Facebook's xctool, where fdstat is the result of calling fstat(fileno(stdout), &fdstat);.

if (!S_ISFIFO(fdstat.st_mode)) {
    [_outputHandle synchronizeFile];
}

https://github.com/facebook/xctool/blob/master/xctool/xctool/Reporter.m#L212

What happens when you run the resulting program through nodejs' exec is that since stdout is not a FIFO, synchronizeFile is called, which results in the following error, as sockets don't support sychronizeFile.

2013-06-13 21:38:51.398 xctool[33336:707] *** Terminating app due to uncaught exception 'NSFileHandleOperationException', reason: '*** -[NSConcreteFileHandle synchronizeFile]: Operation not supported'
*** First throw call stack:
(
    0   CoreFoundation                      0x00007fff9378db06 __exceptionPreprocess + 198
    1   libobjc.A.dylib                     0x00007fff8db163f0 objc_exception_throw + 43
    2   CoreFoundation                      0x00007fff9378d8dc +[NSException raise:format:] + 204
    3   xctool                              0x000000010a0ceab0 -[Reporter close] + 469
    4   xctool                              0x000000010a0cf907 -[TextReporter close] + 67
    5   CoreFoundation                      0x00007fff93789460 -[NSArray makeObjectsPerformSelector:] + 272
    6   xctool                              0x000000010a0c9c40 -[XCTool run] + 2471
    7   xctool                              0x000000010a0c8cb0 main + 244
    8   xctool                              0x000000010a0c8bb4 start + 52
)
libc++abi.dylib: terminate called throwing an exception

Clearly, this is something that xctool could (and probably should) handle better, but it makes you wonder if it wouldn't be better if nodejs could hand down a character device. Is there a specific reason, for why handing down a socket is better?

[bnoordhuis]

Is there a specific reason, for why handing down a socket is better?

A UNIX socket lets you send and receive file descriptors, something you can't do with pipes or FIFOs.

v0.6 actually used pipes to address issues like the one you described above but that got people up in arms because it took away the aforementioned functionality. That's why v0.8 switched back to UNIX sockets.

I guess we could add an option that says 'use a pipe rather than a socket pair' but that would be strictly a workaround for broken programs. It's arguably better to fix the issue upstream, like you did with xctool.

[seishun]

Please, at least document this behavior. I just spent a significant amount of time figuring out why I can't properly run pysandbox via exec – it checks if stdin is either S_ISCHR, S_ISREG or S_ISFIFO.

You might call programs that don't check for S_ISSOCK broken, but this is the second time I'm encountering this issue. Last time it was a bash script that reads from /dev/stdin. It errors with "No such device or address" when stdin is a socket.