Skip to content

Commit 8201c10

Browse files
committed
[runloop] Set up some symbols for generic code.
CFRunLoop has a recurring abstraction for platform-specific code, but it is a little leaky. Plug these leaks: ensure `MACH_PORT_NULL` in the generic, non-platform context is rewritten as `CFPORT_NULL`, and ensure that `kern_return_t` and `KERN_SUCCESS` are defined properly.
1 parent 9bc1a18 commit 8201c10

File tree

1 file changed

+9
-7
lines changed

1 file changed

+9
-7
lines changed

CoreFoundation/RunLoop.subproj/CFRunLoop.c

Lines changed: 9 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -161,6 +161,8 @@ typedef int kern_return_t;
161161
#else
162162

163163
static _CFThreadRef const kNilPthreadT = (_CFThreadRef)0;
164+
typedef int kern_return_t;
165+
#define KERN_SUCCESS 0
164166
#define pthreadPointer(a) a
165167
#define lockCount(a) a
166168
#endif
@@ -654,7 +656,7 @@ static void __CFRunLoopModeDeallocate(CFTypeRef cf) {
654656
dispatch_release(rlm->_queue);
655657
}
656658
#endif
657-
if (MACH_PORT_NULL != rlm->_timerPort) mk_timer_destroy(rlm->_timerPort);
659+
if (CFPORT_NULL != rlm->_timerPort) mk_timer_destroy(rlm->_timerPort);
658660
_CFRecursiveMutexDestroy(&rlm->_lock);
659661
memset((char *)cf + sizeof(CFRuntimeBase), 0x7C, sizeof(struct __CFRunLoopMode) - sizeof(CFRuntimeBase));
660662
}
@@ -842,8 +844,8 @@ static CFRunLoopModeRef __CFRunLoopCopyMode(CFRunLoopRef rl, CFStringRef modeNam
842844
#if USE_DISPATCH_SOURCE_FOR_TIMERS
843845
rlm->_timerFired = false;
844846
rlm->_queue = _dispatch_runloop_root_queue_create_4CF("Run Loop Mode Queue", 0);
845-
mach_port_t queuePort = _dispatch_runloop_root_queue_get_port_4CF(rlm->_queue);
846-
if (queuePort == MACH_PORT_NULL) CRASH("*** Unable to create run loop mode queue port. (%d) ***", -1);
847+
__CFPort queuePort = _dispatch_runloop_root_queue_get_port_4CF(rlm->_queue);
848+
if (queuePort == CFPORT_NULL) CRASH("*** Unable to create run loop mode queue port. (%d) ***", -1);
847849
rlm->_timerSource = dispatch_source_create(DISPATCH_SOURCE_TYPE_TIMER, 0, 0, rlm->_queue);
848850

849851
__block Boolean *timerFiredPointer = &(rlm->_timerFired);
@@ -860,7 +862,7 @@ static CFRunLoopModeRef __CFRunLoopCopyMode(CFRunLoopRef rl, CFStringRef modeNam
860862

861863
#endif
862864
rlm->_timerPort = mk_timer_create();
863-
if (rlm->_timerPort == MACH_PORT_NULL) {
865+
if (rlm->_timerPort == CFPORT_NULL) {
864866
CRASH("*** Unable to create timer Port (%d) ***", rlm->_timerPort);
865867
}
866868
ret = __CFPortSetInsert(rlm->_timerPort, rlm->_portSet);
@@ -2737,7 +2739,7 @@ static int32_t __CFRunLoopRun(CFRunLoopRef rl, CFRunLoopModeRef rlm, CFTimeInter
27372739
Boolean poll = sourceHandledThisLoop || (0ULL == termTSR);
27382740

27392741
#if __HAS_DISPATCH__
2740-
if (MACH_PORT_NULL != dispatchPort && !didDispatchPortLastTime) {
2742+
if (CFPORT_NULL != dispatchPort && !didDispatchPortLastTime) {
27412743
#if TARGET_OS_MAC
27422744
msg = (mach_msg_header_t *)msg_buffer;
27432745
if (__CFRunLoopServiceMachPort(dispatchPort, &msg, sizeof(msg_buffer), &livePort, 0, &voucherState, NULL, rl, rlm)) {
@@ -2867,7 +2869,7 @@ static int32_t __CFRunLoopRun(CFRunLoopRef rl, CFRunLoopModeRef rlm, CFTimeInter
28672869

28682870

28692871
#endif
2870-
if (MACH_PORT_NULL == livePort) {
2872+
if (CFPORT_NULL == livePort) {
28712873
CFRUNLOOP_WAKEUP_FOR_NOTHING();
28722874
cf_trace(KDEBUG_EVENT_CFRL_DID_WAKEUP_FOR_NOTHING, rl, rlm, livePort, 0);
28732875
// handle nothing
@@ -2890,7 +2892,7 @@ static int32_t __CFRunLoopRun(CFRunLoopRef rl, CFRunLoopModeRef rlm, CFTimeInter
28902892
}
28912893
}
28922894
#endif
2893-
else if (rlm->_timerPort != MACH_PORT_NULL && livePort == rlm->_timerPort) {
2895+
else if (rlm->_timerPort != CFPORT_NULL && livePort == rlm->_timerPort) {
28942896
CFRUNLOOP_WAKEUP_FOR_TIMER();
28952897
// On Windows, we have observed an issue where the timer port is set before the time which we requested it to be set. For example, we set the fire time to be TSR 167646765860, but it is actually observed firing at TSR 167646764145, which is 1715 ticks early. The result is that, when __CFRunLoopDoTimers checks to see if any of the run loop timers should be firing, it appears to be 'too early' for the next timer, and no timers are handled.
28962898
// In this case, the timer port has been automatically reset (since it was returned from MsgWaitForMultipleObjectsEx), and if we do not re-arm it, then no timers will ever be serviced again unless something adjusts the timer list (e.g. adding or removing timers). The fix for the issue is to reset the timer here if CFRunLoopDoTimers did not handle a timer itself. 9308754

0 commit comments

Comments
 (0)