Skip to content

Commit aebc211

Browse files
committed
tutorial: use runProcess instead of forkProcess.
Partially fixes haskell-distributed/cloud-haskell#14.
1 parent e412adf commit aebc211

File tree

1 file changed

+13
-20
lines changed

1 file changed

+13
-20
lines changed

‎tutorials/1ch.md

+13-20
Original file line numberDiff line numberDiff line change
@@ -69,15 +69,15 @@ And now we have a running node.
6969

7070
### Sending messages
7171

72-
We start a new process by evaluating `forkProcess`, which takes a node,
73-
a `Process` action - because our concurrent code will run in the `Process`
74-
monad - and returns an address for the process in the form of a `ProcessId`.
75-
The process id can be used to send messages to the running process - here we
76-
will send one to ourselves!
72+
We start a new process by evaluating `runProcess`, which takes a node and
73+
a `Process` action to run, because our concurrent code will run in the
74+
`Process` monad. Each process has an identifier associated to it. The process
75+
id can be used to send messages to the running process - here we will send one
76+
to ourselves!
7777

7878
{% highlight haskell %}
7979
-- in main
80-
_ <- forkProcess node $ do
80+
_ <- runProcess node $ do
8181
-- get our own process id
8282
self <- getSelfPid
8383
send self "hello"
@@ -86,12 +86,11 @@ will send one to ourselves!
8686
return ()
8787
{% endhighlight %}
8888

89-
Lightweight processes are implemented as `forkIO` threads. In general we will
90-
try to forget about this implementation detail, but let's note that we
91-
haven't deadlocked our own thread by sending to and receiving from its mailbox
92-
in this fashion. Sending messages is a completely asynchronous operation - even
93-
if the recipient doesn't exist, no error will be raised and evaluating `send`
94-
will not block the caller, even if the caller is sending messages to itself!
89+
Note that we haven't deadlocked our own thread by sending to and receiving
90+
from its mailbox in this fashion. Sending messages is a completely
91+
asynchronous operation - even if the recipient doesn't exist, no error will be
92+
raised and evaluating `send` will not block the caller, even if the caller is
93+
sending messages to itself!
9594

9695
Receiving works the opposite way, blocking the caller until a message
9796
matching the expected type arrives in our (conceptual) mailbox. If multiple
@@ -118,7 +117,7 @@ main :: IO ()
118117
main = do
119118
Right t <- createTransport "127.0.0.1" "10501" defaultTCPParameters
120119
node <- newLocalNode t initRemoteTable
121-
forkProcess node $ do
120+
runProcess node $ do
122121
-- Spawn another worker on the local node
123122
echoPid <- spawnLocal $ forever $ do
124123
-- Test our matches in order against each message in the queue
@@ -138,13 +137,7 @@ main = do
138137
case m of
139138
-- Die immediately - throws a ProcessExitException with the given reason.
140139
Nothing -> die "nothing came back!"
141-
(Just s) -> say $ "got " ++ s ++ " back!"
142-
return ()
143-
144-
-- A 1 second wait. Otherwise the main thread can terminate before
145-
-- our messages reach the logging process or get flushed to stdio
146-
liftIO $ threadDelay (1*1000000)
147-
return ()
140+
Just s -> say $ "got " ++ s ++ " back!"
148141
{% endhighlight %}
149142

150143
Note that we've used the `receive` class of functions this time around.

0 commit comments

Comments
 (0)