You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are many asynchronous operations which may never complete for one reason or another (reading from sockets / stdio / anything which could produce data, waiting for process exits, etc, etc) and there are many situations where you may want to attempt some operation up until a certain point at which point it isn't relevant / wanted any more (e.g. having a timeout on reading user input from stdin). You could probably of emulate some of these situations by closing the object whenever your chosen cancellation criteria has been met, but the entire object is then un-usable as oposed to just an operation of your choosing currently being performed or waiting to be performed getting stopped.
Part of the answer to this might also be in the coroutine design, in kotlin you can request the cancellation of a coroutine though a function on the object representing a launched coroutine. So if haxe coroutines end up having something similar that might be one approach for this.
Another approach could be the cancellation token technique used in dotnet, this approach is quite nice in that its completely divorced from from their async / tasks and can also be used in standard synchronous / traditional threading code. I'm also not sure if the eventual plan is for all the haxe asys functions to be manually changed to suspending functions or if there is desire to allow them to be used in their current callback style if the user is mad enough, that choice would also effect what cancellation might look like to the asys api.
The text was updated successfully, but these errors were encountered:
There are many asynchronous operations which may never complete for one reason or another (reading from sockets / stdio / anything which could produce data, waiting for process exits, etc, etc) and there are many situations where you may want to attempt some operation up until a certain point at which point it isn't relevant / wanted any more (e.g. having a timeout on reading user input from stdin). You could probably of emulate some of these situations by closing the object whenever your chosen cancellation criteria has been met, but the entire object is then un-usable as oposed to just an operation of your choosing currently being performed or waiting to be performed getting stopped.
Part of the answer to this might also be in the coroutine design, in kotlin you can request the cancellation of a coroutine though a function on the object representing a launched coroutine. So if haxe coroutines end up having something similar that might be one approach for this.
Another approach could be the cancellation token technique used in dotnet, this approach is quite nice in that its completely divorced from from their async / tasks and can also be used in standard synchronous / traditional threading code. I'm also not sure if the eventual plan is for all the haxe asys functions to be manually changed to suspending functions or if there is desire to allow them to be used in their current callback style if the user is mad enough, that choice would also effect what cancellation might look like to the asys api.
The text was updated successfully, but these errors were encountered: