-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Question about terminating gatherFrom in the event of an outer exception #57
Comments
I tried an alternative approach, but it has had interesting (detrimental) results... gatherFromA :: (MonadIO m, MonadUnliftIO m)
=> Int -- ^ Size of the queue to create
-> (TBQueue o -> m ()) -- ^ Action that generates output values
-> m (ConduitT () o m (), Async ())
gatherFromA size scatter = do
chan <- newTBQueueIO (fromIntegral size)
worker <- async (scatter chan)
pure $ (gather worker chan, worker)
where
gather worker chan = do
(xs, mres) <- liftIO $ atomically $ do
xs <- whileM (not <$> isEmptyTBQueue chan) (readTBQueue chan)
(xs,) <$> pollSTM worker
traverse_ yield xs
case mres of
Just (Left e) -> liftIO $ throwIO (e :: SomeException)
Just (Right r) -> return r
Nothing -> gather worker chan When I |
I spoke too soon, if I comment out the call to UPDATE: it appears to be a memory leak somewhere; I haven't yet narrowed down whether it is related to the above change. |
As it turns out, that was a memory leak unrelated to the implementation of I can plan to make a PR of this that implements |
Sorry for the late response. Do I understand correctly that And in this case gatherFrom can be implemented in terms for gatherFromA? In this case I don't see problems with a PR that will introduce it. |
Looking at the
gatherFrom
code (pasted below for convenient), I've got ascatter
function that starts up a TCP server. Ideally, this TCP server would be restarted in the casegatherFrom
is called again due to exception handling at the outer level. Of course, it became obvious that this wasn't possible due to the bound listening socket never being closed. I'm not immediately sure of the best way to handle this, though one possibility is perhaps rewriting the code to usewithAsync
. However, even if possible, I'm not even sure that would be desirable for all use cases.The text was updated successfully, but these errors were encountered: