Node: FileHandle don't allow close while writing/reading

[ronag]

I think I've brought up something similar in the past. Regarding the data race issue with closing file descriptions while they are actively used.

I believe we could enforce this through FileHandle and possibly deprecating non FileHandle based fs ops?

i.e. move the kIsPerformingIO logic from fs streams up one level.

[ronag]

@addaleax

[jasnell]

If we were to introduce a close/destroy distinction in FileHandle this may be possible to do. Essentially, close() would be graceful close (that is, close once current operations complete), and destroy() would be immediate close regardless of any outstanding operations.

[ronag]

and destroy() would be immediate close regardless of any outstanding operations.

Calling close on a fd with outstanding operations is basically undefined behavior (due to the libuv threadpool impl). I don't think we should allow that.

[jasnell]

Fair enough. The behavior, then, could be: close() ... wait for all pending operations to complete, do not cancel uv operations that have not yet been picked up.... destroy(), cancel pending uv operations but still wait for those that have already been picked up by the libuv threadpool.

[jasnell]

fwiw, the key reason for destroy() is to get as close as possible to "destroy this thing as close to immediately as you can".

[ronag]

I'm fine with having both, we could start with implementing destroy as close and in the future improve it if e.g. libuv switches to an async fs api instead of the threadpool.