Является ли блокировка вызова функции плохим процессом проектирования?

Question

Я пишу API, который используется для получения данных из другого приложения. В настоящее время функция предназначена для блокировки до получения данных. На мой взгляд, это ограничивает разработчиков, использующих API, для использования многопоточности или какого-либо многопроцессного проектирования. Так что лучше для функции блокировать или возвращать ноль, а затем спать в течение нескольких миллисекунд, прежде чем пытаться снова.

Обратите внимание, что в другом приложении могут отсутствовать данные для отправки через API в течение неизвестного периода времени.

API написан на C ++

Answer 1

Почему бы не использовать обратный вызов ?

Answer 2

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

Answer 3

Рассмотрим другой вариант: используйте асинхронную транзакцию -> введите request и предоставьте callback address с ticket id. Когда ответ будет доступен, конечная точка службы callbacks вашего приложения с ticket id и вашим результатом; -)

Вам следует избегать, насколько это возможно, блокирования, когда это возможно.

---

Как вы говорите:

Обратите внимание, что в другом приложении могут отсутствовать данные для отправки через API в течение неизвестного периода времени.

В этом случае использование синхронного интерфейса связывает ресурсы без необходимости.

Answer 4

Если вы хотите использовать повторно используемое решение, вы можете применить шаблон асинхронного проектирования, который распространен в .NET, но также может быть реализован в C ++, как продемонстрировано в этом проекте CodeProject .

Нет ничего плохого в том, чтобы обеспечить синхронные и асинхронные вызовы одной и той же функции в интерфейсе.

Лично я бы пошел на эти длины только в том случае, если мне нужно обслуживать несколько запросов (в этом случае, например, вы можете поставить в очередь запросы «BeginOperation») или если в интерфейсе много потенциально асинхронных операций (и я хочу стандартизированный, гибкий шаблон). Если вы можете обрабатывать только один запрос за раз, обычно достаточно тайм-аута.

Answer 5

Когда ваши приложения вызывают функцию API O / S read(), вы ожидаете, что она заблокируется? Конечно, вы делаете - по крайней мере, по умолчанию. В некоторых случаях ioctl позволяет программисту изменять поведение на асинхронное, что особенно распространено в сетевых приложениях.

Вы очень мало прояснили суть вашего API, поэтому подумайте:

• Имеет ли смысл, чтобы пользователь API захотел быть заблокированным? То есть мало что можно сделать, пока он не вернется.
• Если бы вы писали приложение для API, что бы вы ожидали от него? Вам определенно следует написать несколько примеров приложений для собственного образования, а также документировать API.
• Есть ли причина, по которой пользователь API не будет выполнять многопоточные (или разветвленные и т. Д.) Запросы к API?

Answer 6

Вы не сказали, что это за язык, но похоже, что ваш API прослушивает или проверяет какое-то событие, и пользователи API либо блокируют, либо запрашивают ваш API, чтобы определить, произошло ли событие?

Можно ли использовать обратный вызов? Пользователи API будут регистрироваться для получения уведомлений о происходящем событии, и когда ваша библиотека обнаружит это событие, она будет использовать обратный вызов для уведомления всех слушателей.