Bug 118881 – Potential race condition getting NetworkStateNotifier::onLine()

• Status: NEW
• Component: Platform

[Kwang Yul Seo]

WorkerNavigator::onLine() (inherited from NavigatorBase) calls NetworkStateNotifier::onLine() from a worker thread, but network state (m_isOnLine) is updated from the main thread. This is a potential race condition.

[Alexey Proskuryakov]

Could you please elaborate?

I don't think that this is a WebKit bug - any JavaScript code that uses the onLine attribute is racy by definition, because network state can change after it's queried. So, a little more race shouldn't hurt.

[Kwang Yul Seo]

(In reply to comment #1)
> Could you please elaborate?
> 
> I don't think that this is a WebKit bug - any JavaScript code that uses the onLine attribute is racy by definition, because network state can change after it's queried. So, a little more race shouldn't hurt.

Sorry, I should have explained it in more details. Yes, the semantic of onLine is racy and it is definitely not a bug.

But NetworkStateNotifier::m_isOnLine member variable has a data race as there are simultaneous access to the same memory location by multiple threads, where at least one of the accesses modifies the memory location.

Because C++ (even C++11) treats all data races as errors and provides no defined semantics for programs with data races, data races shouldn't be allowed in multi-threaded versions of C++ even if they seem benign.

The data race with m_isOnLine seems benign because at worst the updated value of m_isOnLine might not be visible to worker threads for a very short period time in most modern architectures. But there are many ways to miscompile programs with "benign" data races as explained in the following paper:

https://www.usenix.org/legacy/events/hotpar11/tech/final_files/Boehm.pdf

So my suggestion is to notify network state change through WorkerMessagingProxy (already done in Bug 118832) and keep the value of isOnLine in each WorkerNavigator instance and return it when WorkerNavigator.isOnLine is requested.

[Alexey Proskuryakov]

I agree in theory. In practice, it may be that theoretical correctness of this sort doesn't outweigh cost of more complex code and opportunity cost of working on this. Not sure.