Show pickling issues in notebook on windows

[aseyboldt]

There have been issues about parallel sampling on Windows and Mac, because there the default multiprocessing backend is spawn.
Error messages end up on the console, and sometimes there seems to be a deadlock that I haven't been able to find.
This should work around those two issues: Instead of relying on multiprocessing for pickling we can simply do it ourselves, and pass the pickled objects to the remote process. If unpickling fails we send a normal error message back, that we can show in notebooks.
Also, two more arguments to pm.sample:

• mp_ctx: for explicit control over the multiprocessing context: fork, spawn or forkserver
• pickle_backend: one of pickle or dill (an alternative to pickle that claims that it can pickle some additional objects).

CC @lucianopaz I think that is the issue you were referring to earlier? It would be great if someone could test this on windows a bit.

An example of a model that doesn't pickle:

import theano
import theano.tensor as tt
import numpy as np
import multiprocessing
import pymc3 as pm

@theano.as_op([tt.dvector], [tt.dvector])
def somefunc(a):
    return 2 * np.array(a)

with pm.Model() as model:
    x = pm.Normal('x', shape=2)
    pm.Normal('y', mu=somefunc(x), shape=2)
    #pm.Normal('y', mu=2, shape=2)

with model:
    step = pm.Metropolis()
    trace = pm.sample(step=step, mp_ctx='spawn')

[AlexAndorra]

Thanks a lot @aseyboldt, this looks very helpful! I'll wait for @lucianopaz's review before merging though.
I had two questions:

1. Contrary to the title of the PR, it seems like this solves the pickling issue on WinOS and MacOS, doesn't it?
2. Since the crux of the issue seems to be the spawn default, why don't we set the context to forkserver by default on MacOS? It seems cumbersome if users have to change the context manually each time.

[aseyboldt]

Contrary to the title of the PR, it seems like this solves the pickling issue on WinOS and MacOS, doesn't it?

Depends on what "the pickling issue" is. It does not solve problems where we can't sample on win because the model can't be pickled, but it does solve the issue that the error message ends up at the incorrect place or that there is a deadlock.

Since the crux of the issue seems to be the spawn default, why don't we set the context to forkserver by default on MacOS? It seems cumbersome if users have to change the context manually each time.

I now set the default context to forkserver on macos, and removed the previous forkserver context in init.py. This is a different issue than the one above, where things crash because of seaborn.

[codecov]

Codecov Report

Merging #3991 into master will increase coverage by 0.06%.
The diff coverage is 81.69%.

@@            Coverage Diff             @@
##           master    #3991      +/-   ##
==========================================
+ Coverage   86.56%   86.62%   +0.06%     
==========================================
  Files          88       88              
  Lines       14020    14062      +42     
==========================================
+ Hits        12136    12181      +45     
+ Misses       1884     1881       -3     

Impacted Files	Coverage Δ
pymc3/__init__.py	95.23% <ø> (+1.90%)	⬆️
pymc3/parallel_sampling.py	88.36% <81.15%> (+2.59%)	⬆️
pymc3/sampling.py	86.03% <100.00%> (+0.01%)	⬆️

[lucianopaz]

This looks great @aseyboldt! I had to go through it a couple of times because I'm definitely out of my league with all the multiprocessing communication that has to go on here.

I think that I understood the basic idea:

1. Pickle the step method in the master process
2. Start worker processes that each create their own Process instance that has the communication msg_pipe set up.
3. Send the picked step method through the pipe and wait to hear any error.

What I don't fully understand is why the remote connection of the process adapter has to be closed immediately after spawning the worker processes? The adapter still has to receive messages through the message pipe, but doesn't it also need the remote connection to send a potential keyboard interrupt? Or to send an abortion message to every process after a single process raised an error? Anyway, I still think that this PR is great and is worth merging ASAP.

[lucianopaz]

The code coverage error seems to be mostly because the dill backend is never tested

[aseyboldt]

Maybe a small example helps to illustrate why we have to close one of the local pipes.

We could use the multiprocessing pipe in a normal single threaded program (there would be faster ways...)

import multiprocessing

# Create a pipe, the two endpoints are conn1 and conn2
conn1, conn2 = multiprocessing.Pipe()

# We can send and recieve from both
conn1.send_bytes(b'hallo')
conn2.recv_bytes()
# b'hallo'

conn2.send_bytes(b'hi')
conn1.recv_bytes()
# b'hi'

# We close one of the endpoint
conn2.close()

# Sending and recieving will fail

conn1.send_bytes(b'hallo')
# BrokenPipeError, because there is nobody we could send to

conn1.recv_bytes()
# EOFError, (EOF=end of file) because nobody could be sending any more data

Now we do something like this:

import multiprocessing

# Create a pipe, the two endpoints are conn1 and conn2
conn1, conn2 = multiprocessing.Pipe()

# Start new process and give a *copy* of conn2 to the subprocess
start_new_worker(conn2)

# The new worker errors out, it will close its copy of conn2
# Our local copy of conn2 is still open though!

# We don't know yet, that the worker is dead, and wait for the next message
conn1.recv_bytes()
# No BrokenPipeError, because conn2 is still open, and the operating system doesn't
# know that it won't be sending anything.
# Instead, we just wait for the other end (conn2) to send something. But because
# our process is the only one that could send something, and because we are currently
# busy waiting for messages, there can never be a message from conn2, so we
# wait forever.

[aseyboldt]

I'll add a test with dill tomorrow, and fix the conflict with master.

[AlexAndorra]

Thanks for your explanantion @aseyboldt, quite clear now!

I now set the default context to forkserver on macos, and removed the previous forkserver context in init.py. This is a different issue than the one above, where things crash because of seaborn.

Ah yeah, mixed up both issues, but thanks for changing this.

I think the codecov error is a false negative due to the introduction of dill? I'll let you merge if you think this is ready 😉

[aseyboldt]

dill is tested now, the issue is that there is some error handling code when sending a message to the workers that isn't tested. I don't really know how to trigger that case though.
I think it is fine to merge.

[lucianopaz]

Great work @aseyboldt! The code coverage looks fine, the project's total coverage will increase a bit, but for some reason the patch itself is less covered. I'll go ahead and merge.