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
I am writing a synchronous computational library (which does not use rayon by itself), with an option to have HTTP interface on top of it. HTTP interface uses axum/tokio, but as soon as there is any CPU-heavy request to handle, it spawns a rayon task (using tokio-rayon crate so far, as far as I understood from #679, there is no built-in functionality for that so far).
The load depends on what comes in a request, and it's hard to predict by just looking at arguments. My HTTP server is configured with tower timeouts, so that too heavy tasks are killed.
The issue is, so far all i can do in an error handler is to return HTTP error code, while rayon will keep processing it, sometimes until the bitter kill signal. Are there workarounds, which do not involve me spamming my library with channel arguments throughout all its functions, and adding checkpoints where the lib checks for messages and decide if it should stop processing and return an error?
The text was updated successfully, but these errors were encountered:
There's no arbitrary way to kill a task -- it's basically the same problem as thread cancellation. Every call has some expected return value that we can't just ignore, and threads may be blocked on the result of other threads as well.
Are there workarounds, which do not involve me spamming my library with channel arguments throughout all its functions, and adding checkpoints where the lib checks for messages and decide if it should stop processing and return an error?
A channel or a simple atomic flag will do, and I think that's probably the best possible. You can decide from that how to handle your cancellation, either stuff like try_fold returning an error, or just panic and maybe catch that at a higher level (assuming you don't have panic=abort).
Yes, I just finished reading up on issues with thread cancellation (dangers of it were and probably still are unfamiliar to me). I will try using atomic flag for termination, thanks.
I am writing a synchronous computational library (which does not use rayon by itself), with an option to have HTTP interface on top of it. HTTP interface uses
axum
/tokio
, but as soon as there is any CPU-heavy request to handle, it spawns a rayon task (usingtokio-rayon
crate so far, as far as I understood from #679, there is no built-in functionality for that so far).The load depends on what comes in a request, and it's hard to predict by just looking at arguments. My HTTP server is configured with
tower
timeouts, so that too heavy tasks are killed.The issue is, so far all i can do in an error handler is to return HTTP error code, while rayon will keep processing it, sometimes until the bitter kill signal. Are there workarounds, which do not involve me spamming my library with channel arguments throughout all its functions, and adding checkpoints where the lib checks for messages and decide if it should stop processing and return an error?
The text was updated successfully, but these errors were encountered: