Семафоры POSIX на Mac OS X: альтернатива sem_timedwait
Это основано на политике маршрутизации. Ядро Linux может работать с несколькими таблицами маршрутизации и правилами, которые определяют, для какого трафика используется конкретная таблица маршрутизации. Вы можете увидеть эти правила с помощью ip rule, если iproute2 доступно в вашей системе. Маршруты в определенной таблице могут быть перечислены с ip route list table <nr/name> (используйте all как имя, чтобы увидеть маршруты во всех таблицах).
Правила могут соответствовать различным свойствам, связанным с сетевым пакетом (или их комбинацией), например, IP-адреса, входящие / исходящие интерфейсы, метки Netfilter или UID процессов. Последнее, в частности, используется для исключения / включения конкретных приложений. Каждое приложение запускается уникальным пользователем со своим UID. Это позволяет контролировать, использует ли конкретное приложение таблицу маршрутизации, которая направляет трафик на устройство TUN.
Например, использование VPN исключительно для трех приложений добавляет правила с этими селекторами:
... uidrange 10010-10010 lookup 1049
... uidrange 10062-10062 lookup 1049
... uidrange 10094-10094 lookup 1049
Таблица маршрутизации 1049 (это изменяется для каждого нового экземпляра VPN) содержит маршрут, который направляет трафик на устройство TUN. .
С другой стороны, если те же три приложения исключены из VPN, селекторами являются:
... uidrange 0-10009 ...
... uidrange 10011-10061 ...
... uidrange 10063-10093 ...
... uidrange 10095-99999 ...
Как вы можете видеть, трафик со всех UID (в диапазоне 0-99999), кроме три ранее замеченных направлены в таблицу маршрутизации для устройства TUN.
4 ответа
It's likely that the timeout is important to the operation of the algorithm. Therefore just using sem_wait() might not work.
You could use sem_trywait(), which returns right away in all cases. You can then loop, and use a sleep interval that you choose, each time decrementing the total timeout until you either run out of timeout or the semaphore is acquired.
A much better solution is to rewrite the algorithm to use a condition variable, and then you can use pthread_cond_timedwait() to get the appropriate timeout.
Рассматривали ли вы возможность использования переносимой среды выполнения Apache? Он предустановлен на каждом Mac OS X Box и во многих дистрибутивах Linux и поставляется с независимой от платформы оболочкой для параллелизма потоков, которая работает даже в MS Windows:
http://apr.apache.org/docs/apr/1.3/ group__apr__thread__cond.html
Не могли бы вы попытаться имитировать функциональность вызова sem_timedwait (), запустив таймер в другом потоке, который вызывает sem_post () после истечения времени таймера, если он не был вызван основным потоком что должно вызывать sem_post ()?
Если вы можете просто использовать MP API:
- MPCreateSemaphore/MPDeleteSemaphore
- MPSignalSemaphore/MPWaitOnSemaphore
MPWaitOnSemaphore существует с kMPTimeoutErr, если указанный таймаут превышен без подачи сигнала.