> > I'm not sure concurrent.futures is the culprit, rather than > > multiprocessing itself (or perhaps even some core Python functionality). > > Actually, the threading-based part of concurrent.futures probably works > > fine. > > Well, "the culprit" really is FreeBSD. However, concurrent.futures > apparently makes freehanded use of semaphores, in a way that the > FreeBSD authors didn't expect them to be used (if they expected them > to be used at all, that is).
It seems to be multiprocessing as much as concurrent.futures itself. Apparently a basic multiprocessing queue already uses two (interprocess) locks and one semaphore. And, again, the threading-based API in concurrent.futures should work fine anyway. Do you suggest we selectively disable the process-based API? Regards Antoine. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
