мультипроцессорная обработка> Manager ()> Ошибка RLock:

Question

мультипроцессорная обработка> Manager ()> Ошибка RLock:

1

У меня есть коллекция объектов multiprocessing.Process в списке, и все они используют один и тот же экземпляр того, что я буду называть "безопасной для процесса", для связи в безопасном для процесса (потокобезопасном, но с процессами) способе родительский процесс, ответственным за управление потоками.

Когда дочерний процесс переходит в очередь, он вызывает ProcessSafeQueue(). Enqueue(), который сначала получает мультипроцессор.Manager> RLock, затем записывает в очередь и, наконец, освобождает блокировку.

В этом случае это был pid дочернего процесса. Здесь прослеживается ошибка.

Traceback (most recent call last): 
File /usr/lib/python2.5/site-packages/my_project/some_module.py, line 87, in send_data
    q.enqueue(os.getpid())
File /usr/lib/python2.5/site-packages/my_project/some_module.py, line 33, in enqueue
    self.lock.acquire()
File /usr/lib/python2.5/site-packages/processing/managers.py, line 979, in acquire
    return self._callMethod(\'acquire\', (blocking,))
File /usr/lib/python2.5/site-packages/processing/managers.py, line 740, in _callMethod
    self._connect()
File /usr/lib/python2.5/site-packages/processing/managers.py, line 727, in _connect
    connection = Client(self._token.address, authkey=self._authkey)
File /usr/lib/python2.5/site-packages/processing/connection.py, line 187, in Client
    answerChallenge(c, authkey)
File /usr/lib/python2.5/site-packages/processing/connection.py, line 425, in answerChallenge
    message = connection.recvBytes()

И вот настоящая ошибка:

IOError: [Errno 11] Ресурс временно недоступен

Мне интересно, может ли кто-нибудь помочь мне понять, почему я могу получить эту ошибку после успешного применения приложения в течение ~ 7 часов или около того.

bitcycle 11 июль 2011, в 07:21

Источник

Теги:

python

multiprocessing

reentrantlock

ioerror

2 ответа

1

У меня была аналогичная проблема, и я решил это, удалив socket.setdefaulttimeout.

wisefish 04 июль 2013, в 06:25

0

Интересное решение. Мне не приходилось сталкиваться с этим какое-то время (с тех пор, как я перешел на использование C ++ для промежуточного программного обеспечения :). Я рад, что вы нашли что-то, что решает это для вас.
bitcycle 04 июль 2013, в 18:20
0

Явная установка с помощью socket.setdefaulttimeout (None) исправила это для меня. См. Bugs.python.org/issue6056 .
Craig McDaniel 07 нояб. 2014, в 16:27

Ещё вопросы

Интересное решение. Мне не приходилось сталкиваться с этим какое-то время (с тех пор, как я перешел на использование C ++ для промежуточного программного обеспечения :). Я рад, что вы нашли что-то, что решает это для вас.
Явная установка с помощью socket.setdefaulttimeout (None) исправила это для меня. См. Bugs.python.org/issue6056 .

bitcycle · Accepted Answer · 2011-07-28T03-06-00.000Z

Ответ здесь заключается в том, что ошибка полностью вводит в заблуждение. Resource temporarily unavailable действительно означает, что при чтении сокета произошла некоторая ошибка. Это может быть ошибкой auth или что для чтения просто нет данных (хотя я не уверен, почему это создало бы ошибку... на практике это происходит). Решение здесь заключается в том, чтобы подавить ошибку и повторить попытку.

[Обновление после нескольких лет опыта работы с параллелизмом в Python]

Я обнаружил, что разработка моей модели параллелизма для уменьшения/удаления - в целом потребность в механизмах синхронизации (блокировки, очереди или семафоры) упростила мой дизайн и сделала работу с меньшей хрупкостью и без ошибки, описанной выше.