- libdispatch-dev - lists.macosforge.org

Queue size
by Danilo Egea 29 Sep '10

29 Sep '10

First, sorry my english... Are possible define the queue size in GCD? Example: Define the max. number of task run simultaneous in a queue. -- Danilo Egêa Gondolfo Email/MSN - daniloegea(a)yahoo.com.br Skype - daniloegea Twitter - http://twitter.com/daniloegea Blog - http://daniloegea.wordpress.com __________________________________________________ Fale com seus amigos de graça com o novo Yahoo! Messenger http://br.messenger.yahoo.com/

4 5

Some slides about libdispatch
by cee1 07 Sep '10

07 Sep '10

Hi all, I've written some slides about libdispatch: - http://dev.lemote.com/files/upload/people/~chenj/libdispatch/libdispatch.pdf - http://dev.lemote.com/files/upload/people/~chenj/libdispatch/libdispatch-ev… Here are odp versions: - http://dev.lemote.com/files/upload/people/~chenj/libdispatch/libdispatch.odp - http://dev.lemote.com/files/upload/people/~chenj/libdispatch/libdispatch-ev… -- Regards, - cee1

1 0

Question about event handling in libdispatch
by cee1 02 Sep '10

02 Sep '10

Hi all, A kevent can associate with more than one source. What if: 1. A kevent of EVFILT_READ indicating that data is available to read. 2. A series of sources associating with this kevent are waken up. 3. One source handler fetches the data. 4. The rest source handlers will find there is no data available to read in monitored fd. It seems waking up more than one source doesn't make sense here? The rest source handlers will simply fail to read. -- Regards, - cee1

3 4

Update FreeBSD information on the libdispatch page?
by Robert N. M. Watson 01 Sep '10

01 Sep '10

If someone could update the following text: > libdispatch on FreeBSD > 2009-10-21 > The libdispatch library is available in the FreeBSD ports collection for experimental use on FreeBSD 9.x. Several kqueue kernel enhancements are planned for FreeBSD 8.1 in order to allow the libdispatch port to be used on FreeBSD 8.x as well. > > Information is available on the FreeBSD wiki about installing the libdispatch, llvm-devel, and compiler-rt ports allowing full use of the blocks extension to C with libdispatch. libdispatch is now appropriate for (we think) production use as of FreeBSD 8.1; to use it, just install the libdispatch port or package and the rest should follow automatically. I've just updated the FreeBSD wiki page, wiki.freebsd.org/GCD, to reflect this as well. (If the above turns out not to work so well, I also accept bug reports!) Robert

1 0

Re: [libdispatch-dev] libpthread_workqueue released
by Mark Heily 04 Aug '10

04 Aug '10

On 08/02/2010 09:17 AM, Chen Jie wrote: > Hi mark, > > I've read some code snippets of libpthread_workqueue 0.1. It doesn't > implement the over-commit feature, am I right? > Not yet. It also doesn't implement priority levels, and the algorithm for managing the size of the thread pool is very simplistic. > Does over-commit means when some threads in thread pool are blocked, a > new thread will be created even thread pool is full? When the blocked > threads are waken, the total number of active threads will exceed the > size of thread pool? > That sounds like the general idea, yes. The size of the thread pool is dynamic, and will be determined by the overall load on the system, so having "too many threads" is okay. As soon as the load exceeds the capacity of the system, the number of threads will be automatically reduced. - Mark

1 0

Question about "better assembly generation" in _dispatch_continuation_pop
by cee1 02 Aug '10

02 Aug '10

Hi all, I've read "_dispatch_continuation_pop" in src/queue.c(line 338). For async dispatch_continuation_t, it will first free, then execute it. The comment says this will generate better assembly, why? Regards, -- cee1

2 1

Results from running libdispatch tests on Solaris using libkqueue and libdispatch with patches
by Joakim Johansson 30 Jul '10

30 Jul '10

Hi, If anyone is interested, the output of the working unit tests for libdispatch on Solaris 10 is attached below. This is done with libdispatch r188 + the patches posted to the list the last few days built together with libkqueue r271 together with a few patches posted on the libkqueue list. dispatch_priority seems to fail spuriously sometimes (even though it passed in the example below) and the starfish latency boundary test sometimes fails - this is on a Xeon 5500 box with 8 cores (of which 4 is HT). When running the test suite, a very large number of threads is created for some tests: 386 during dispatch_priority 35 during dispatch_priority2 257 during starfish It seems a bit excessive, what would be expected on such a configuration not having support for pthread_workqueue? I will try it using Mark Heily’s userspace pthread_workqueue implementation as well and see how that works. Joakim —— node5:~/gcd/trunk/testing> ./dispatch_api ================================================== [TEST] Dispatch (Public) API [PID] 16120 ================================================== Actual: 412850 Expected: 412850 [PASS] dispatch_get_main_queue node5:~/gcd/trunk/testing> ./dispatch_c99 ================================================== [TEST] Dispatch C99 [PID] 16135 ================================================== Actual: 412830 Expected: 412830 [PASS] dispatch_get_main_queue node5:~/gcd/trunk/testing> ./dispatch_cascade ================================================== [TEST] Dispatch Cascade [PID] 16150 ================================================== maxcount = 2464 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * ** * * * * * * * * * ** * * * * * * * * * ** * * *** * * * * * node5:~/gcd/trunk/testing> ./dispatch_debug ================================================== [TEST] Dispatch Debug [PID] 16165 ================================================== node5:~/gcd/trunk/testing> ./dispatch_priority ================================================== [TEST] Dispatch Priority [PID] 16180 ================================================== LOW: 64 **************************************** DEFAULT: 60 ************************************** HIGH: 68 ******************************************* Actual: 192 Expected: 192 [PASS] blocks completed Actual: 64 Expected: <68 [PASS] high priority precedence node5:~/gcd/trunk/testing> ./dispatch_priority2 ================================================== [TEST] Dispatch Priority (Set Target Queue) [PID] 16195 ================================================== Actual: 413150 Expected: 413150 [PASS] q[i] Actual: 415a10 Expected: 415a10 [PASS] q[i] Actual: 415ac0 Expected: 415ac0 [PASS] q[i] LOW: 58 ************************************* DEFAULT: 67 ****************************************** HIGH: 67 ****************************************** Actual: 192 Expected: 192 [PASS] blocks completed Actual: 58 Expected: <67 [PASS] high priority precedence node5:~/gcd/trunk/testing> ./dispatch_starfish ================================================== [TEST] Dispatch Starfish [PID] 16210 ================================================== lap: 10 count: 1000 delta: 832448041 ns math: 415.808212 ns / lap Actual: 415 Expected: <1000 [PASS] Latency lap: 9 count: 1000 delta: 789866055 ns math: 394.538489 ns / lap Actual: 394 Expected: <1000 [PASS] Latency lap: 8 count: 1000 delta: 976664387 ns math: 487.844349 ns / lap Actual: 487 Expected: <1000 [PASS] Latency lap: 7 count: 1000 delta: 1625163520 ns math: 811.769990 ns / lap Actual: 811 Expected: <1000 [PASS] Latency lap: 6 count: 1000 delta: 1527922124 ns math: 763.197864 ns / lap Actual: 763 Expected: <1000 [PASS] Latency lap: 5 count: 1000 delta: 1293263436 ns math: 645.985732 ns / lap Actual: 645 Expected: <1000 [PASS] Latency lap: 4 count: 1000 delta: 1755776727 ns math: 877.011352 ns / lap Actual: 877 Expected: <1000 [PASS] Latency lap: 3 count: 1000 delta: 2045621497 ns math: 1021.788960 ns / lap Actual: 1021 Expected: <1000 [FAIL] Latency (dispatch_starfish.c:75) dispatch_starfish.c:75 lap: 2 count: 1000 delta: 997176198 ns math: 498.090009 ns / lap Actual: 498 Expected: <1000 [PASS] Latency lap: 1 count: 1000 delta: 1204968309 ns math: 601.882272 ns / lap Actual: 601 Expected: <1000 [PASS] Latency node5:~/gcd/trunk/testing> ./queue_finalizer ================================================== [TEST] Dispatch Queue Finalizer [PID] 16225 ================================================== Actual: 413390 Expected: 413390 [PASS] dispatch_queue_new Actual: 72f36169c7132463 Expected: 72f36169c7132463 [PASS] finalizer ran node5:~/gcd/trunk/testing>

2 3

PATCH - bugfix for dispatch_priority.c spurious failures where actual blocks completed != expected
by Joakim Johansson 28 Jul '10

28 Jul '10

I’ve had some problems with spurious failures of dispatch_priority/dispatch_priority2 tests on Solaris. It actually turned out to be a small bug in the test: ‘iterdone’ being size_t would wrap around rather than being negative (as it seems was assumed in the code). It could be fixed by changing the condition to look from the wraparound, or alternatively by consistently changing the use of size_t for the various ‘counts’ to use the long type instead. I’ve attached both flavors of the fix for consideration, both variants works fine now without spurious failures. Cheers, Joakim First patch variant checking for wraparound: --------------------------------- octo.tbricks.com:gcd/trunk/testing> svn diff dispatch_priority.c Index: dispatch_priority.c =================================================================== --- dispatch_priority.c (revision 188) +++ dispatch_priority.c (working copy) @@ -100,8 +100,8 @@ histogram(); test_stop(); exit(0); - } else if (iterdone > 0) { - __sync_add_and_fetch(count, 1); + } else if ((iterdone > 0) && (iterdone <= ITERATIONS)) { // We need to check that iterdone is not > ITERATIONS, as size_t is signed + __sync_add_and_fetch(count, 1); // 'iterations' wraps around and some thread may otherwise increase 'count' when the test is done } } ———————————————— Alternative patch changing the type from size_t to long ———————————————— octo.tbricks.com:gcd/trunk/testing> svn diff dispatch_priority.c Index: dispatch_priority.c =================================================================== --- dispatch_priority.c (revision 188) +++ dispatch_priority.c (working copy) @@ -48,21 +48,21 @@ int priorities[PRIORITIES] = { DISPATCH_QUEUE_PRIORITY_LOW, DISPATCH_QUEUE_PRIORITY_DEFAULT, DISPATCH_QUEUE_PRIORITY_HIGH }; union { - size_t count; + long count; char padding[64]; } counts[PRIORITIES]; -#define ITERATIONS (size_t)(PRIORITIES * BLOCKS * 0.50) -size_t iterations = ITERATIONS; +#define ITERATIONS (long)(PRIORITIES * BLOCKS * 0.50) +long iterations = ITERATIONS; void histogram(void) { - size_t maxcount = BLOCKS; - size_t sc[PRIORITIES]; + long maxcount = BLOCKS; + long sc[PRIORITIES]; - size_t total = 0; + long total = 0; - size_t x,y; + long x,y; for (y = 0; y < PRIORITIES; ++y) { sc[y] = counts[y].count; } @@ -86,10 +86,10 @@ void cpubusy(void* context) { - size_t *count = context; - size_t iterdone; + long *count = context; + long iterdone; - size_t idx; + long idx; for (idx = 0; idx < LOOP_COUNT; ++idx) { if (done) break; } octo.tbricks.com:gcd/trunk/testing>

1 0

Solaris portability - PATCH - m4/private-extern.m4
by Joakim Johansson 27 Jul '10

27 Jul '10

As mentioned, one final niggle was in the detection of the support for '__attribute__((visibility("hidden")))’. It turns out that this breaks on Solaris when you actually try to reference such a symbol with: -— conftest.c:56: warning: visibility attribute not supported in this configuration; ignored —— even though a compile with such declarations works just fine. The attached patch modifies the detection to not just compile such a symbol, but also to reference it through an assignment and enabling the treatment of warnings as errors. When tested, this yields the correct detection of support on both Darwin and Solaris (yes/no respectively). I believe this is the final patch needed to build libdispatch cleanly on Solaris using: ----- sh ./autogen.sh ./configure --disable-static gmake CFLAGS=-m64 —— (requires an installed version of libkqueue) Joakim ------------------------------------------- octo.tbricks.com:~/Network/gcd/trunk> svn diff m4/private-extern.m4 Index: m4/private-extern.m4 =================================================================== --- m4/private-extern.m4 (revision 188) +++ m4/private-extern.m4 (working copy) @@ -4,10 +4,12 @@ # AC_DEFUN([DISPATCH_C_PRIVATE_EXTERN], [ +AC_LANG_WERROR + AC_CACHE_CHECK([for __attribute__((visibility("hidden")))], dispatch_cv_hidden_visibility_attribute, [ - AC_TRY_LINK([], - [extern __attribute__ ((visibility ("hidden"))) int foo;], + AC_TRY_LINK([int foo; extern __attribute__ ((visibility ("hidden"))) int foo;], + [foo = 0;], [dispatch_cv_hidden_visibility_attribute=yes], [dispatch_cv_hidden_visibility_attribute=no])]) octo.tbricks.com:~/Network/gcd/trunk>

1 0

libdispatch now available in Debian GNU/Linux
by Mark Heily 27 Jul '10

27 Jul '10

I am pleased to announce that libdispatch is now included in the official Debian GNU/Linux package repository [1]. This package includes support for the "blocks" extension to C. I would like to express my gratitude to Julien Blache for sponsoring these packages, testing them, and providing great feedback and help improving the quality of the packages. I'd like to thank Robert Watson for accepting various patches to improve the portability of libdispatch. I will be submitting some more Linux-related patches in the near future. I would also like to thank the EGLIBC maintainers for accepting a patch to remove the uses of "__block" within <unistd.h> that conflict with the Blocks API. And finally, I want to thank Apple for releasing libdispatch as open source, and I hope that it is adopted as the foundation for writing software that can take full advantage of the multi-core and multi-processor systems that are becoming the norm. Cheers, - Mark [1] http://packages.debian.org/squeeze/libdispatch0 http://packages.debian.org/squeeze/libdispatch-dev

1 0