ICollection, наборы только для чтения и синхронизация. Действительно ли это правильно?
Paho-клиент имеет встроенный блок try / wait, который оборачивает вызов на on_message, чтобы предотвратить сбой сетевого потока из-за плохого поведения обратных вызовов.
Если вы хотите знать, где происходит сбой вашего кода, вы можете добавить свою собственную попытку / ожидание во внутреннюю часть функции on_message, чтобы показать проблему. Что-то вроде:
def on_message(client, userdata, msg):
try:
msg = msg.payload.decode()
print("topic:", msg.topic)
print("Received Message: {}".format(msg))
expect Exception, e:
print(e)
3 ответа
Да это - проблема в некоторых случаях. Даже при том, что набор только для чтения и не может быть изменен, объекты, ссылки набора не только для чтения. Таким образом, если клиенты будут использовать SyncRoot для выполнения блокировки, то они не будут ориентированы на многопотоковое исполнение при изменении объектов, на которые ссылается набор.
Я рекомендовал бы добавить:
private readonly object syncRoot = new object();
к Вашему классу. Возвратите это как SyncRoot, и Вы хороши для движения.
Я предполагаю, что проблема была бы то, если бы клиенты использовали Ваш синхронизирующий корень для достижения блокировки не только набор, но и что-то еще. Предполагаемый они кэшировали размер набора - или возможно, "какое подмножество этого набора соответствует предикату" - они обоснованно предположили бы, что могли использовать Ваш SyncRoot для защиты и набора и их другого участника.
Лично я едва использую SyncRoot вообще, но я думаю, что было бы разумно всегда возвратить то же самое.
Это кажется очень нечетным для возврата другого объекта каждый раз... на самом деле, я очень редко (если когда-нибудь) использую подход SyncRoot, поскольку часто я должен синхронизироваться между несколькими объектами и т.д., таким образом, отдельный объект более значим.
Но если данные действительно неизменны (только для чтения), почему не только возвращают false от IsSynchronized?
Ре GC - любой такой объект обычно было бы недолгим и собиралось бы в GEN0. Если бы у Вас есть поле с объектом (для блокировки), она продлилась бы пока набор, но скорее всего не причинит боль так или иначе...
Если бы Вам нужна блокировка, я испытал бы желание просто иметь a:
private readonly object lockObj = new object();
Вы могли также использовать ленивый подход к только "новому" это при необходимости, который делает определенное количество смысла, если Вы на самом деле не ожидаете, что кто-либо попросит синхронизирующую блокировку (возвращает false к IsSynchronized).
Другой общий подход должен возвратить "это"; это сохраняет вещи простыми, но рискует конфликтами с некоторым другим кодом с помощью объекта в качестве блокировки для несвязанной цели. Редкий, но возможный. Это - на самом деле подход это [MethodImpl] использование для синхронизации.