On 2013-05-16 10:23 AM, David Rajchenbach-Teller wrote:
On 5/16/13 3:03 PM, Ehsan Akhgari wrote:
Is this not the OS.File issue that Vladan mentioned?

My point is that there doesn't seem to be enough use cases to warrant a
new infrastructure to handle shutdown dependencies.

Well, as we expand our use of OS.File, we start observing a number of
issues, most of which do not seem to be due to OS.File itself, but more
generally to (chrome) workers.

Here are a few:
- clients of OS.File need to write their data before OS.File shuts down
– that's Vladan's remark;
- JS Workers (including OS.File's I/O worker) need to be properly
initialized before shut down or to cancel themselves nicely upon
shutdown – that's Gabriele's remark;
- OS.File itself needs to be informed of shut down to (asynchronously)
collect information and print warnings about leaking file descriptors,
and also to start rejecting additional requests.

If OS.File can detect shutdown at the correct time, then it seems like all of the above issues are going to be easy to fix. Which makes me think of all of these as one use case (please correct me if I'm wrong.)

That's from the top of my head, I am sure that I am missing a few.

As we move as much code as possible to workers/threads, I believe that
we are going to suffer from a growing number of such issues. So, yes, I
am convinced that we need a way to handle dependencies.

Moreover, I believe that we need to make dependencies somewhat explicit,
otherwise we will at some point end up with unsatisfiable implicit
dependencies and we will need large refactorings to get around these.

A dependency system for startup/shutdown isn't free. It's going to have runtime cost, and it's going to make the code more complicated. Given the fact that we've managed to get by just fine without one for years, I think we should continue to do that, and in the cases where you want specific ordering, just use hard-coded notifications (such as profile-before-change2 -- BTW, that's a terrible name!).

Cheers,
Ehsan

_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to