Replies: 1 comment
-
That seems like a reasonable approach. I think in that world where you have a bunch of callers unsafely running effects you are to a certain extent pushed into that world where you also managed those fibers using "unsafe" data types. One alternative would be to have all of the callers just unsafely offer requests to a queue. Then you could create a number of fibers that pull requests from the queue and process them. The queue could also accept "shutdown" messages and once a shutdown message was received the fiber receiving it could set a |
Beta Was this translation helpful? Give feedback.
-
Suppose I have a service class that lives inside a non-functional, synchronous, multithreaded application. This class implements access to some kind of remove REST API, and the application calls methods of the class to make various requests against this API. These methods start ZIO effects (using
Runtime.unsafe
) and immediately return control back to the application, leaving the effects running in the background.When the application needs to shut down, calls the
close
method of the class. This method first sets the flag to prevent starting of other effects (if different threads ask to do API requests), and then it should wait until all previously started effects finish their execution before allowing the application to shut down, so that all responses from the remote API would be properly processed.I have difficulties with the "waiting" part. Sure, I can maintain a thread-safe
Set
(for example, one produced byConcurrentHashMap.newKeySet()
), saveFiber
s associated with running effects in it (and remove fibers associated with completed effects), and then callFiber.awaitAll
when I need to wait for their completion. However, this feels cumbersome. Is there a better (maybe more idiomatic/ZIO-centric) way to do it?Beta Was this translation helpful? Give feedback.
All reactions