The API to initialize I/O resources is inherently racy

[eric@adblockplus.org]

Semantics of the API

JsEngine uses post-construction, dynamic initialization of the file system it exposes through the _fileSystem JS object. In particular, it's possible to change the underlying file system while I/O is pending. This interface has an inherent race condition about which file system, the new or the old, a particular I/O operation is acting upon.

The problem is not confined to I/O operations considered individually. The API also permits changes of the file system between two I/O operations, because the API has no provision to ensure that the file system has not changed.

In practice, dynamic initialization provide no benefit. A client typically instantiates an engine, immediately initializes a file system for it, and then never changes thereafter.

The other kinds of I/O, web request and console, use the same kind of API, have the same problems, and are amenable to the same solutions.

Correct behavior

There are many possible correct behaviors that are free of race conditions. Here are some possibilities:

1) Remove the file system from the engine entirely. This eliminates the race condition entirely by eliminating any opportunity for it, pushing responsibility for eliminating any races onto users of JsEngine. Instead an auxiliary class would take responsibility for both a file system and its exposed JS interfaces. This removes the permanent existence of any JS file system object, which, unless statically initialized, creates the opportunity for a race condition in the first place.

If the owner of a JsEngine instance were to manage a file system and its associated JS object, it could initialize both in its constructor, providing the effect of static initialization of the file system without any explicit code dealing with life spans at all. See #4693 for a related issue, which would use this pattern for FilterEngine.

2) Initialize the file system of the engine statically at the time of construction. This removes the race condition by removing dynamic initialization.

3) Provide some mechanism for keeping dynamic initialization and providing the client the means to bind individual I/O operations to specific file systems, either explicitly or with a "current file system" context. Any mechanism like this complicates the API significantly and does not seem to provide any actual benefit.

[eric@adblockplus.org]

This issue is related to #1582 to provide atomic file operations, which are only well-defined with respect to a single file system.

[abpbot]

Some commits referencing this issue have landed:

• ​Issue 4832 - remove API allowing changing of LogSystem after Initialization of JsEngine
• ​Issue 4832 - remove API allowing changing of FileSystem after Initialization of JsEngine

[takken3]

spam