search

jepst / CloudHaskell

A distributed computing framework for Haskell
http://hackage.haskell.org/package/remote
BSD 3-Clause "New" or "Revised" License
347 stars 22 forks source link

Question about ProecessM monad #11

Closed aslatter closed 12 years ago

aslatter commented 12 years ago

I've been digging through the sources of Cloud Haskell trying to understand what it is about - it looks nice.

On the Picky-details side of things, it looks like the ProcessM Monad is set up similar to a State monad, but it could almost be a Reader Monad, except for the functions 'setLogConfig' and 'buildPid'. If it weren't for these functions, ProcessM could be defined as:

newtype ProcessM a = ProcessM {runProcessM :: Process -> IO a} deriving Typeable

which would simplify the implementation (and perhaps improve the performance of (>>=) and friends).

It looks like 'buildPid' is only called when a process doesn't know which port it is listening on. It's a bit hard for me to follow the process creation code - if there was a way for the parent process which creates the child to calculate the port before-hand instead of after the fact the monad stack could be trimmed down.

For 'setLogConfig', we could just put the local log config in an MVar and be done with it.

This would change the semantics of 'forkProcessWeak' - changes to the log config after calling 'forkProcessWeak' would be seen in both threads.

Since 'forkProcessWeak' is only used in one place which doesn't this shouldn't be a problem.

Anyway I'm probably missing something about how process creation works, so there might e a reason this isn't a good approach.

jepst commented 12 years ago

Your observations are correct: ProcessM could have been implemented, with just a few tweaks, as a Reader monad. I didn't do it that way because the design evolved during the implementation. Originally, there were no mutable fields, and it was much closer to a State monad. I didn't realize that that approach was untenable until I had already written a fair chunk of code, and it seemed not worth it to go back and make changes. While redesigning the ProcessM monad might make the implementation a little cleaner, I don't think it would noticably improve performance for any application.

As I recall, the convoluted nature of buildPid in the process startup code has to do with the fact that we want to be able to run processes before the node is initialized. So process code calling getSelfPid and such should block until the network port is bound. This, too, could be gotten around.

I apologize for the general ugliness of parts of the code and my laziness in getting things cleaned up.

Let me know if you have any more questions.

aslatter commented 12 years ago

No need to apologize - existing work is better than super clean work. Like I'd guessed, there was a reason for the Pid oddness even if I didn't know it.

You can leave this open at your discretion.

Also - do you have a public email address? Your old uni. email bounces.

jepst commented 12 years ago

Yep, feel free to write me at the address associated with the Cloud Haskell package on Hackage:

http://hackage.haskell.org/package/remote-0.1.1