Я не думаю, что ваш анализ верен.
Вы говорите, что процесс заходит в тупик, потому что stdin и stdout используются процессом создателя PDF. Однако, поскольку это было начато с использованием модуля подпроцесса, fds, которые являются stdin и stdout для PDF-creator-process, являются просто обычными конвейерными fds для FastCGI-процесса. Нет никаких причин, по которым вы не могли бы одновременно выполнять несколько текущих вызовов «связи» подпроцесса.
Однако учтите, что «общаться» - это блокирующий вызов. Пока один поток в вашем процессе выполняет comnunicate, этот поток больше не сможет ничего делать, например, обслуживать запросы HTTP для изображений.
В этом случае одно из решений - сделать ваш сервер многопоточным. Я удивлен, что это не так, поскольку большинство веб-серверов могут одновременно обслуживать несколько запросов (в разных потоках), поэтому это должно «просто работать».
Но, возможно, вы делаете что-то не так в том, как вы используете "общаться". Я написал небольшой пример того, как использовать несколько текущих вызовов «общаться» одновременно в одном и том же процессе, возможно, вы можете использовать его в качестве основы для решения. Не зная больше о вашей проблеме, трудно быть лучше.
import subprocess
from threading import Thread
sp1 = subprocess.Popen(["bash","-c","sleep 2;echo output1"],
stdin=subprocess.PIPE,
stdout=subprocess.PIPE,shell=False,close_fds=True)
sp2 = subprocess.Popen(["bash","-c","sleep 1;echo output2"],
stdin=subprocess.PIPE,
stdout=subprocess.PIPE,shell=False,close_fds=True)
def readfrom(which,sp):
print "Thread #%d starting."%(which,)
(stdout, stderr) = sp.communicate()
print "Thread #%d finished, output: %s"%(which,stdout)
t1=Thread(target=readfrom,args=(1,sp1))
t2=Thread(target=readfrom,args=(2,sp2))
t1.start()
t2.start()
t1.join()
t2.join()