mergeSources terminates only after both sources have terminated (?)

[kjameslubin]

Is there a way to have mergeSources terminate after one of the sources has terminated? I can show you a code sample if need be. Basically, my use case is that I've made a source out of a Postgres trigger/notify thread, and a source that is is the appSource for a tcp server, and merged them. When the appSource terminates, the trigger thread sticks around - which is a file descriptor leak.

I could likely roll something with e.g. STM to make the trigger thread stop but I thought you might have done it already given how mergeSources is implemented.

[cgaebel]

This hasn't been done yet. A pull request with the function (pretty much copy+pasted from mergeSources, with some tweaks), documentation, tests, and a good name will be accepted.

[qnikst]

Hello, @kjameslubin sorry for the very late response.

I was going to start working on this function but I understood that I do not understand the semantics we want to have in presence of exceptions. Also I don't see the most preferable way, or simple API, simple solution that would allow to alter the behaviour.

What are the questions:

1. What to do on the normal exit of one of the threads?
   As I understand we need to close all the threads for the sources (by sending an exception), and we should close the inner buffer channel. But should be close the channel before or after sending an exception? In the latter case we may not see some messages from the threads we have killed. Should we control the type of the exception we use? Do we need to wait and ensure that the thread has exited, or it's ok that it's received an exception?
2. Should be immediately stop producing the messages or we should emit every one that were in the inner buffer?
   I'd like to say that we should, but I'm not sure. In the case that you are describing it may worth losing all the messages as the normal flow is not possible anymore.
3. When thread exits with an exception should we rethrow it in the main thread?
   Usual approach for such libraries is that we should rethrow an exception, but again I'm not sure.

If you help me to define the sane semantics I would be able to provide such a function. But more I'm thinking about that the more I lean to the solution that the library should not have such a primitive, instead it should provide enough building blocks that allows to write a merge function with the semantics that is exactly needed for the scenario.