Здравствуйте, salvequick, Вы писали:
Посмотрите
man 2 kqueue, фильтр
EVFILT_TIMER:
Establishes an interval timer with the data timer identified by ident. When adding a timer, data specifies the timeout period and fflags can be set to one of the following: following:
NOTE_SECONDS data is in seconds
NOTE_USECONDS data is in microseconds
NOTE_NSECONDS data is in nanoseconds
NOTE_ABSOLUTE data is an absolute timeout
If fflags is not set, the default is milliseconds. The timer will be periodic unless
EV_ONESHOT is specified. On return, data contains the number of times the timeout has
expired since the last call to kevent() or kevent64(). This filter automatically sets
the EV_CLEAR flag internally.
Совместимость в пределах BSD.
#include <sys/cdefs.h>
#include <assert.h>
#include <errno.h>
#include <stdio.h>
#include <stdbool.h>
#include <strings.h>
#include <sys/time.h>
#include <sys/event.h>
#include <stdlib.h>
int main()
{
int akq=kqueue();
struct kevent64_s aTimerEvent;
EV_SET64(&aTimerEvent,1,EVFILT_TIMER,EV_ADD|EV_ENABLE,NOTE_SECONDS,1,0,0,0);
//add the event
int aSuccess=kevent64(akq,&aTimerEvent,1,NULL,0,0,NULL);
if(aSuccess<0)
abort();
while(1)
{
struct kevent64_s anEvent;
int anEventCount=kevent64(akq,NULL,0,&anEvent,1,0,NULL);
if(anEventCount<0)
abort();
if(anEventCount==1)
{
printf("timer!\n");
}
}
}
Еще взгляните на всякие sleep'ы и wait'ы
Здравствуйте, kaa.python, Вы писали:
KP>Написал небольшой обзорчик.
В обзоре так все красиво )
А на самом деле я тут столкнулся в дальнейшем с тем что RunLoop надо запускать в отдельном потоке.
т.к после запуска CFRunLoopRun() выполнение основного потока блокируется.
Следовательно работа с API тамеров будет кардинально отличаться от timer_create к примеру.
Вспоминал я "добрыми" словами людей кто придумал CFRunLoop не раз в процессе разработки.
Выяснилсоь еще, что с сигналами MACOS по другому работает немного .
Если в линукс вызвать функцию raise(signo) многократно из разных потоков с практически отсутствующей паузой то обработчик сигнала будет вызван столько раз сколько была вызвана raise(signo).
А вот в MAC OS это число меняется, и отчего зависит сколько раз будет вызван обработчик вообще непонятно.
Похоже что имеются отличия в реализации механизма сигналов в ядрах Linux и Darwin.
Здравствуйте, kaa.python, Вы писали:
KP>Я, может быть, что-то путаю, но POSIX не гарантирует количество вызовов обработчика сигнала. Есть гарантия что он будет вызван и даже советуется расчитывать на то, что обработчик будет вызван только один раз. Не?
я читаю сейчас single unix specification : 2.4 Signal concepts.
и нигде не нашел утверждения, что будет и как следует работать системе если pending нескольок одинаковых сигналов.
есть фразы вроде
When multiple unblocked signals, all in the range SIGRTMIN to SIGRTMAX, are pending, the behavior shall be as if the implementation delivers the pending unblocked signal with the lowest signal number within that range. No other ordering of signal delivery is specified.
Но тут нет указания на то что это одинаковые сигналы, я так понял что речь о разных сигналах идет.
When a signal is generated by the sigqueue() function or any signal-generating function that supports the specification of an application-defined value, the signal shall be marked pending and, if the SA_SIGINFO flag is set for that signal, the signal shall be queued to the process along with the application-specified signal value. Multiple occurrences of signals so generated are queued in FIFO order.
а здесь вообще указание на FIFO порядок обработки
Источник здесь
http://www.opengroup.org/onlinepubs/000095399/functions/xsh_chap02_04.html#tag_02_04
