Closed mrakgr closed 1 year ago
Also even if you have, would that throw an exception in the async expression that is waiting on the reply channel?
Er, does JS even have finalizers for that matter?
I was wondering if you've made sure to implement the finalizers so that they close out the side on the other machine? The connection being closed should also cause a disposal as well.
For this first part, the answer, for now, would be no. There is no treatment for that case. For that second part, I'm not sure. The implementation for the reply channel is very barebone, containing only one GUID identifying the value channel and another for the exception channel. It should be possible to save that identifier and reconstruct the channel so you can answer the front end even after disconnection.
Even though this scenario is plausible, it's not being supported at the moment. We could add an option to close all channels when the connection is dropped and add a way to restore broken channels, so both possibilities are supported.
would that throw an exception in the async expression that is waiting on the reply channel?
I believe that should be the expected behavior, and honestly, I think that the exception serializer doesn't even work. Maybe we could also change it to expect a string that will turn into the exception Message
while we are adding those features.
Thank you. Apart from how Fable handles .NET finalizers on the JS side, that answers my questions.
I've done a search and it seems that ES2021 supports finalizers and weak references, so it might be possible for Fable to support it in the future if it doesn't now.
I am thinking about using them, but it occurred to me that if I drop them there is no way the garbage collector will know that since it would be on a different machine. I was wondering if you've made sure to implement the finalizers so that they close out the side on the other machine? The connection being closed should also cause a disposal as well.