Opened on 01/23/2017 at 02:10:13 PM

Closed on 07/27/2017 at 08:13:26 AM

Last modified on 10/08/2019 at 05:50:49 PM

#4832 closed defect (fixed)

The API to initialize I/O resources is inherently racy

Reported by: Assignee:
Priority: Unknown Milestone:
Module: Libadblockplus Keywords:
Cc: Blocked By:
Blocking: Platform: Unknown / Cross platform
Ready: no Confidential: no
Tester: Unknown Verified working: no
Review URL(s):


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.

Attachments (0)

Change History (6)

comment:1 Changed on 01/23/2017 at 02:12:36 PM by

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

comment:2 Changed on 07/26/2017 at 02:45:32 PM by sergz

  • Review URL(s) modified (diff)

comment:3 Changed on 07/26/2017 at 02:47:20 PM by sergz

  • Review URL(s) modified (diff)

comment:5 Changed on 07/27/2017 at 08:13:26 AM by sergz

  • Resolution set to fixed
  • Status changed from new to closed

comment:6 Changed on 03/15/2019 at 06:31:16 AM by takken3


Last edited on 10/08/2019 at 05:50:49 PM by kzar

Add Comment

Modify Ticket

Change Properties
as closed .
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from (none).
Note: See TracTickets for help on using tickets.