State of the Linux port (without blocks support)
Hi, Robert Watson schrieb:
Has anyone else noticed that getting libdispatch to run on a new OS is the easy bit, and that figuring out the auto*/libtool/pkg-config/etc stuff is the hard bit? :-)
I did recognize the irony and I don't want to underestimate your work either, but getting libdispatch to compile is just the first step. The real problems are going to arise thereafter, as we're now able to run the test suite. I also would like to thank all developers who are replying that quickly on the list, and Mark Heily for developing libkqueue. All libraries and programs have been compiled with GCC 4.4.1. Please note that I ran the tests manually, because make -C <build-of-libdispatch>/testing check might report pass, e.g.: Actual: 193 Expected: 192 [FAIL] blocks completed (/home/mario/diplom/src/libdispatch/testing/dispatch_priority.c:82) /home/mario/diplom/src/libdispatch/testing/dispatch_priority.c:82 Actual: 29 Expected: <36 [PASS] high priority precedence PASS: dispatch_priority Here are the results: dispatch_api: pass dispatch_c99: pass dispatch_cascade: pass dispatch_debug: pass dispatch_priority: fail ================================================== [TEST] Dispatch Priority [PID] 3369 ================================================== LOW: 128 ******************************************************************************** DEFAULT: 23 *************** HIGH: 42 *************************** Actual: 193 Expected: 192 [FAIL] blocks completed (/home/mario/diplom/src/libdispatch/testing/dispatch_priority.c:82) /home/mario/diplom/src/libdispatch/testing/dispatch_priority.c:82 Actual: 128 Expected: <42 [FAIL] high priority precedence (/home/mario/diplom/src/libdispatch/testing/dispatch_priority.c:83) /home/mario/diplom/src/libdispatch/testing/dispatch_priority.c:83 dispatch_priority2: fail ================================================== [TEST] Dispatch Priority (Set Target Queue) [PID] 3944 ================================================== Actual: 0x240e010 Expected: 0x240e010 [PASS] q[i] Actual: 0x240e350 Expected: 0x240e350 [PASS] q[i] Actual: 0x240e400 Expected: 0x240e400 [PASS] q[i] LOW: 63 **************************************** DEFAULT: 67 ****************************************** HIGH: 62 *************************************** Actual: 192 Expected: 192 [PASS] blocks completed Actual: 63 Expected: <62 [FAIL] high priority precedence (/home/mario/diplom/src/libdispatch/testing/dispatch_priority.c:83) /home/mario/diplom/src/libdispatch/testing/dispatch_priority.c:83 dispatch_starfish: fail laps 10-1 pass, but the task doesn't return and spins forever (one thread). queue_finalizer: pass ciao, Mario
On Thu, 19 Nov 2009, Mario Schwalbe wrote:
dispatch_priority: fail ================================================== [TEST] Dispatch Priority [PID] 3369 ================================================== LOW: 128 ******************************************************************************** DEFAULT: 23 *************** HIGH: 42 *************************** Actual: 193 Expected: 192
This is a bug/feature in libdispatch; the version of the code without pthread work queues does not propagate libdispatch to the pthreads doing the work.
dispatch_starfish: fail laps 10-1 pass, but the task doesn't return and spins forever (one thread).
I see frequent failed latency deadlines on FreeBSD with this, but have mostly been testing on a VM that may be part of the problem for me. All the functional tests complete, and the total realtime clock is 17(ish) seconds on the VM. Robert N M Watson Computer Laboratory University of Cambridge
Hi, Robert Watson schrieb:
On Thu, 19 Nov 2009, Mario Schwalbe wrote:
dispatch_starfish: fail laps 10-1 pass, but the task doesn't return and spins forever (one thread).
I see frequent failed latency deadlines on FreeBSD with this, but have mostly been testing on a VM that may be part of the problem for me. All the functional tests complete, and the total realtime clock is 17(ish) seconds on the VM.
I traced down the problem to the following short test (similar to dispatch_api): #include <dispatch/dispatch.h> #include <stdio.h> #include "dispatch_test.h" void work(void *context __attribute__((unused))) { printf("[PASS] doing some work\n"); test_stop(); } int main(void) { test_start("Dispatch After"); //dispatch_queue_t default_q = dispatch_get_global_queue(0, 0); //test_ptr_notnull("dispatch_get_global_queue", default_q); //// work all: //dispatch_after_f(DISPATCH_TIME_NOW, default_q, NULL, work); //dispatch_after_f(dispatch_time(DISPATCH_TIME_NOW, 0), default_q, NULL, work); //dispatch_after_f(dispatch_time(DISPATCH_TIME_NOW, 1 * NSEC_PER_SEC), default_q, NULL, work); dispatch_queue_t main_q = dispatch_get_main_queue(); test_ptr_notnull("dispatch_get_main_queue", main_q); // works: //dispatch_after_f(DISPATCH_TIME_NOW, main_q, NULL, work); //dispatch_after_f(dispatch_time(DISPATCH_TIME_NOW, 0), main_q, NULL, work); // doesn't work: dispatch_after_f(dispatch_time(DISPATCH_TIME_NOW, 1 * NSEC_PER_SEC), main_q, NULL, work); dispatch_main(); return 0; } those dispatch_after_f calls that are commented out, do work. however, the last one, results in _dispatch_wakeup to be called endlessly which tries to get the lock, fails, and returns NULL. ciao, Mario
participants (2)
-
Mario Schwalbe
-
Robert Watson