rodlogic

@edsko thanks for the additional info and details. @hyperthunk there is another pull request with another iterative improvement to GenServer: now threading server state through the handlers (init, handle, terminate)....

@edsko @hyperthunk Committed a few additional changes to support the handling of CallStop and CastStop (this is when the server can instruct a termination after handling the call/cast). I am...

@hyperthunk ``` I had a play with this too and found it pretty awkward. The dispatchers need to take StateT ... {args...} but the state constructor needs a parameter (say...

@hyperthunk CH issue #69 is behind us and a good base for us to continue. It was a great move, btw, to raise this as a CH issue. Regarding the...

Yes, this is an important topic for discussions since it could affect the core GenServer design. I don't have a strong opinion about this either way at this point so...

@edsko Could you chip in to give us an idea of Cloud Haskell's design wrt to channels vs process messages here? First, can one reliably use both at the same...

Ok, considering that there are use cases for untyped handle_info messages AND the fact that it is not possible to handle both channel and process messages at the same time...

fyi:See this pull request by Simon Marlow: https://github.com/haskell-distributed/distributed-process/commit/847abf494233523dba7d0b40628c3af9e870be91 It seems to address the issue of efficiently receiving channel and process messages.

The latest build failure is happening because the latest exit/catchExit changes have not been released by distributed-process, or so it seems. ``` src/Control/Distributed/Platform/GenServer.hs:52:60: 573 Module `Control.Distributed.Process' does not export `exit'...

> if we can come up with a version of this scheme that works for us both and assign issues to ourselves, then as long as we're able to split...