As discussed earlier, Factor is single-threaded from the point of view of the OS. If we want to make use of multiple cores, we need a way to spawn Factor processes and communicate between them. Factor implements two different models of message-passing concurrency: the actor model, which is based on the idea of sending messages asynchronously between threads, and the CSP model, based on the use of channels.

As a warm-up, we will make a simple example of communication between threads in the same process.

We can start a thread that will receive a message and print it repeatedly:

A thread whose quotation starts with receive and calls itself recursively behaves like an actor in Erlang or Akka. We can then use send to send messages to it. Try "hello" over send and then "threading" over send.

Channels are slightly different abstractions, used for instance in Go and in Clojure core.async. They decouple the sender and the receiver, and are usually used synchronously. For instance, one side can receive from a channel before some other party sends something to it. This just means that the receiving end yields control to the scheduler, which waits for a message to be sent before giving control to the receiver again. This feature sometimes makes it easier to synchronize multithreaded applications.

Again, we first use a channel to communicate between threads in the same process. As expected, USE: channels. You can create a channel with <channel>, write to it with to and read from it with from. Note that both operations are blocking: to will block until the value is read in a different thread, and from will block until a value is available.

We create a channel and give it a name with

Then we write to it in a separate thread, in order not to block the UI

We can then read the value in the UI with

We can also invert the order:

This works fine, since we had set the reader first.

Now, for the interesting part: we will start a second Factor instance and communicate via message sending. Factor transparently supports sending messages over the network, serializing values with the serialize vocabulary.

Start another instance of Factor, and run a node server on it. We will use the word <inet4>, that creates an IPv4 address from a host and a port, and the <node-server> constructor

Here we have used f as host, which just stands for localhost. We will also start a thread that keeps a running count of the numbers it has received.

Once we have started the server, we can make a thread available with register-remote-thread:

Now we switch to the other instance of Factor. Here we will receive a reference to the remote thread and start sending numbers to it. The address of a thread is just the address of its server and the name we have registered the thread with, so we obtain a reference to our adder thread with

Now, we reimport send just to be sure (there is an overlap with a word having the same name in io.sockets, that we have imported)

and we can start sending numbers to it. Try 3 over send, and then 8 over send - you should see the running total printed in the other Factor instance.

What about channels? We go back to our server, and start a channel there, just as above. This time, though, we publish it to make it available remotely:

What you get in return is an id you can use remotely to communicate. For instance, I just got 326546621698456955263335657082068225943 (yes, they really want to be sure it is unique!).

We will wait on this channel, thereby blocking the UI:

In the other Factor instance we use the id to get a reference to the remote channel and write to it

In the server instance, the message should be printed.

Remote channels and threads are both useful to implement distributed applications and make good use of multicore servers. Of course, it remains the question how to start worker nodes in the first place. Here we have done it manually - if the set of nodes is fixed, this is actually an option.

Otherwise, one could use the io.launcher vocabulary to start other Factor instances programmatically.