[Q] incremental parallel composition

[ggreif]

I am lacking the understanding how to initiate a parallel tribe of ClSFs which can expand. Think a listening socket, which receives connect attempts, and runs 'till closure of connections.

So we start out with zero workers, then add blocking receivers on each new socket, each successively receiving from the stream (think Stdio, but for several connections). When all sockets are done, the number of parallel ClSFs should go back to zero.

I have not found a comparable example yet. What comes close is pool from https://github.com/turion/rhine-tutorial, but that uses sequence, so I'd get a blockage on each consequent connection. But maybe I can use that as a template with parallel combination instead...

[turion]

It depends. Do you want them to work synchronously? (I.e. all ticks simultaneously?) Then use pool or sequence. I don't understand what you mean by "a blockage on each consequent connection"), what's the problem there?

If they all run independently, it's probably easiest to launch a new Rhine (something like forkIO $ flow $ myclsf @@ myclock connectionparams) for each connection.

We haven't looked into how to deal with the list effect extensively enough (see e.g. https://github.com/ivanperez-keera/dunai/issues/86) to give a beautiful answer (with an API like exceptions), but research is ongoing.

[ggreif]

With sequence the socket descriptors would be visited in order one after another; if one does not receive any bytes, then it would block all the others. So I want them all to read asynchronously.

I see, I can use an MVar for getting out received datagrams from a forkIO $ flow-ed rhine. Or are there more idiomatic collect-like usage patterns?

[turion]

It's more idiomatic to create a Chan and then use an Event clock (see https://github.com/turion/rhine/blob/develop/rhine-examples/src/EventClock.hs) in a supervisor thread to collect the results.

[turion]

Ah I get your point. Yes, that sounds like an asynchronous use case. If you have a toy app you'd like me to review, I'll happily do so!

(Feel free to close the issue if you think your question has been answered)

[ggreif]

Thanks, those hints were gold! I went with the threadsExample example, as I have several feeder and only one processing thread. Works like a charm :-)

I tried to drain the Chan myself, which caused strange behaviour, until I rediscovered tagS...

[turion]

Great! Any chance I'll get to see your app some time in the future?

[ggreif]

Will you present rhine at Regensburg Meetup? Then I'll surely can give a glimpse at it. I am porting it from Clash, because I need to cross-compile and as such TemplateHaskell (-dependent) libs are an impediment. The app is in its infancy, but already demo-able.

On 6/28/18, Manuel Bärenz notifications@github.com wrote:

Great! Any chance I'll get to see your app some time in the future?

-- You are receiving this because you modified the open/close state. Reply to this email directly or view it on GitHub: https://github.com/turion/rhine/issues/93#issuecomment-401054778

[turion]

[Replying in private]