<mgorny>
mattip, cfbolz: redis(-py) seems to be another package affected by the spawn problem -- here we can't pickle _thread.Lock being part of the client
<mgorny>
i suppose the only solution is to have all consumers using redis + multiprocessing force "fork" method, correct?
<mgorny>
though i suppose passing threading.Lock() to a forked process is kinda weird
<mgorny>
maybe they should switch to multiprocessing.Lock instead?
<cfbolz>
mgorny: and they simply don't work on mac, I assume?
<cfbolz>
I don't know, the real solution would be to find this bug :-(
<cfbolz>
but I am a quite stuck with that at the moment
<mgorny>
cfbolz: probably not, i find it hard to test since it relies on working redis instance and their test suite relies on docker
<cfbolz>
right
<mgorny>
after resolving locks, now lambdas are a problem
<mgorny>
basically a lot of work to make redis client class serializable, and i'm not even sure if they should really be doing that
<cfbolz>
mgorny: basically the fork default lets projects be a little bit lazy. because some unpicklable things will be around in the child process from the fork
<mattip>
redis-py does support macOS, but maybe that specific feature is disabled?