freedomjs / freedom

Embracing a distributed web
http://freedomjs.org
Apache License 2.0
515 stars 52 forks source link

Allow modules to run cleanup procedures on shutdown #295

Closed bemasc closed 3 years ago

bemasc commented 9 years ago

Currently, freedom modules do not get any notification that they are being destroyed, so they must have public cleanup functions (e.g. UdpSocket::destroy()), and their owners must perform cleanup tasks explicitly before freeing the module. This multistep sequence is inconvenient and complex. It would be better if parent modules could simply destroy their child modules, and the child module could perform appropriate cleanup tasks before the destructor completed.

agallant commented 9 years ago

It does seem like at least some relevant code already exists, e.g.: https://github.com/freedomjs/freedom/commit/a8e7491074b79c00319fd15d87b5bbd3b9359387

That is, parent modules are trying to free things - but it is less clear how much the child module is really notified and how other necessary cleanup can occur. There is a closeHandlers object that looks like it could be populated with cleanup functions that would be executed, but that is still in the parent module and not the child.

Just to make sure I understand, is this an instance of explicit cleanup that you'd like to streamline? https://github.com/uProxy/uproxy-lib/blob/bb5589cc26b4fad3cbe1196455450bf73e738d67/src/churn-pipe/churn-pipe.ts#L490-L496

And if so, is the idea that this could simply be a one-liner (freedom['core.udpsocket'].close(socket);) and the socket would then "know what to do" from there?

bemasc commented 9 years ago

You're right. The child is notified, or at least it can be: https://github.com/freedomjs/freedom/blob/master/providers/core/core.xhr.js#L22 . Maybe I just need to understand exactly what freedom's behavior guarantees are for this onClose function ... e.g. why is it wrapped in a setTimeout?

Yes, you have the right idea about what I'm trying to accomplish. Ideally recursively: no explicit cleanup of children would be needed, because freedom will inform each provider when it should free its resources.

agallant commented 9 years ago

Rough start at documenting behavior - https://github.com/freedomjs/freedom/wiki/freedom.js-structure:-module-cleanup

A perhaps useful example: https://github.com/freedomjs/freedom/blob/9614244a09008c36a5d13520717347516a64fe11/providers/core/core.view.js#L22-L26

For now I am documenting this as core providers only, as the code suggests that these flags are used in the registration of such modules (https://github.com/freedomjs/freedom/blob/9614244a09008c36a5d13520717347516a64fe11/src/api.js#L45). I'm not certain if this is actually a hard limitation or not, and in any case if it is then we probably want it not to be.

agallant commented 9 years ago

I believe that the setTimeout approach is indeed for core providers, however I do think it should be reasonably possible to do something comparable for other modules. https://github.com/freedomjs/freedom/blob/9614244a09008c36a5d13520717347516a64fe11/src/module.js#L227-L248

Will continue working on making this more "official."