Node System host write - need to loop since writeSync might not write all bytes in one request

[dbaeumer]

fs.writeSync is speced in a way that it returns the byes written which is not handled correctly the the write function of the node system host.

We say issues with the tsserver when writing more than 64KB using fs.writeSync on the Mac running under electron (io.js)

[mihailik]

io.js source indeed has a separate path for writing string (versus buffer), but it's not clear whether it flushes the whole string or just a part.

fs.js line 669:

fs.writeSync = function(fd, buffer, offset, length, position) {
  if (buffer instanceof Buffer) {
    if (position === undefined)
      position = null;
    return binding.writeBuffer(fd, buffer, offset, length, position);
  }
  if (typeof buffer !== 'string')
    buffer += '';
  if (offset === undefined)
    offset = null;
  return binding.writeString(fd, buffer, offset, length, position);  // <-- see here
};

Is there any way to reproduce a partial write for writeSync for string?

[mihailik]

Also see fs.writeSync truncates long lines in io.js repo — seems to be a known bug?

[CyrusNajmabadi]

maybe break if toWrite is 0?

[dbaeumer]

@mihailik Regarding exposure: I am not sure I can follow the argument. The buffer API is only exposed to the node system host which is already very node specific. It depends on fs, path, ... For an emulated environment I would expect someone to implement the system host functions.

We only saw the issue on Mac under Electron which is based on io,js. It happend when the tsserver wrote a large response to the console (see #3758)

[dbaeumer]

Sorry issue is #2758

[mihailik]

@dbaeumer being node-specific is one thing, having large exposure to node API is another.

If you want to run tsc in a non-node environment, such as a browser, Rhino/Nashorn, FireFox OS — every new dependency on a platform is a headache. For me it's a very practical concern, I do run tsc emulating node api subset in browser.

Given that the root cause seems to be an io.js bug #1541, is there any way to limit the workaround to tsserver itself?

Tsserver is indeed much more dependent on V8/node, including ES5.
Tsc is ES3-compliant and very compatible with various environments.

[dbaeumer]

@mihailik IMO the current node system is already buffer dependent. See the implementation of readFile. It reads the file as a buffer and checks the first two bytes for a BOM.

In general I think the tsc compiler should be programmed against the spec of writeSync even if in all implementation they currently write all content if it is a string. The implementation could change and still be spec compliant.

[mhegazy]

👍

[mhegazy]

@zhengbli can you give this a quick look.

[zhengbli]

Confirmed it runs fine with Sublime Text plugin. 👍

[mhegazy]

thanks!

[zhengbli]

Saw this problem again on Sublime with Node v4.2.1 on OSX. Even with the merged PR the problem still exists. The problem is the fs.writeSync would throw an exception EAGAIN: resource temporarily not available, watch, which terminates the partial write and crashes the server.