opengcd-discuss Mailing List for OpenGCD
Portable implementation of Grand Central Dispatch
Brought to you by:
mheily
You can subscribe to this list here.
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(6) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2013 |
Jan
(2) |
Feb
(4) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Jaymie S. <jst...@ko...> - 2014-05-27 03:01:13
|
Hi. I'm considering using OpenGCD in a project, so I created a small Android app to try it out. In doing so, I ran into a possible problem with timers. Using the code below, I set a timer to go off every 1 second. But the timer is not as precise as I'd expected. Sometimes it's late by several tenths of a second. Any idea why that would be? dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0); dispatch_source_t timer = dispatch_source_create(DISPATCH_SOURCE_TYPE_TIMER, 0, 0, queue); dispatch_source_set_timer(timer, dispatch_time(DISPATCH_TIME_NOW, NSEC_PER_SEC), NSEC_PER_SEC, 0); dispatch_source_set_event_handler(timer, ^{ struct timespec res; clock_gettime(CLOCK_REALTIME, &res); double time = res.tv_sec + (double) res.tv_nsec / 1e9; __android_log_print(ANDROID_LOG_INFO,"test","%f\n", time); }); dispatch_resume(timer); A more general question — Would you consider the 0.2 release stable, or more of a work in progress? (Is http://sourceforge.net/p/opengcd/wiki/Android/ up to date? I'm guessing not, as it predates the 0.1 release.) Is OpenGCD the most mature available port of libdispatch to Android? Thanks, Jaymie Strecker |
From: 신영호 <you...@lg...> - 2013-03-14 12:00:54
|
Dear Mark. I tried to compile and make opengcd with baseproject in Ubuntu. And then, An error has occurred. See the following message. youngho.shin@aot-gsm:~/work/opengcd-test$ make cd libBlocksRuntime && make make[1]: Entering directory `/home/youngho.shin/work/opengcd- test/libBlocksRuntime' clang -DHAVE_CONFIG_H -I. -DBlocksRuntime_EXPORTS - DHAVE_SYNC_BOOL_COMPARE_AND_SWAP_INT -DHAVE_SYNC_BOOL_COMPARE_AND_SWAP_LONG -std=c99 -Wall -Wextra -W -pedantic -Wno-unused-parameter -o runtime.o - fPIC -DPIC -c runtime.c clang -DHAVE_CONFIG_H -I. -DBlocksRuntime_EXPORTS - DHAVE_SYNC_BOOL_COMPARE_AND_SWAP_INT -DHAVE_SYNC_BOOL_COMPARE_AND_SWAP_LONG -std=c99 -Wall -Wextra -W -pedantic -Wno-unused-parameter -o data.o -fPIC - DPIC -c data.c clang -o libBlocksRuntime.so -shared -fPIC -L . -Wl,- soname,libBlocksRuntime.so.0 runtime.o data.o ar cru libBlocksRuntime.a runtime.o data.o libBlocksRuntime.a make[1]: libBlocksRuntime.a: Command not found make[1]: *** [libBlocksRuntime.a] Error 127 make[1]: Leaving directory `/home/youngho.shin/work/opengcd- test/libBlocksRuntime' make: *** [libBlocksRuntime-build-stamp] Error 2 The reason is that because there is not $(RANLIB) definition. So, I added on following line. youngho.shin@aot-gsm:~/work/opengcd-test/libBlocksRuntime$ svn diff makeconf/makeconf/installer.rb Index: makeconf/makeconf/installer.rb =================================================================== --- makeconf/makeconf/installer.rb (revision 402) +++ makeconf/makeconf/installer.rb (working copy) @@ -29,6 +29,7 @@ :sbindir => '$(EPREFIX)/sbin', :sysconfdir => '$(PREFIX)/etc', :sharedstatedir => '$(PREFIX)/com', + :ranlib => 'ranlib', # Package-specific directories :pkgincludedir => '$(INCLUDEDIR)/$(PACKAGE)' I wonder if it is correct. But I success configure and make both baseproject and androidproject. Also I found out a typographical error. youngho.shin@aot-gsm:~/work/opengcd-test/libBlocksRuntime$ svn diff makeconf/makeconf/baseproject.rb Index: makeconf/makeconf/baseproject.rb =================================================================== --- makeconf/makeconf/baseproject.rb (revision 402) +++ makeconf/makeconf/baseproject.rb (working copy) @@ -628,7 +628,7 @@ printf "checking for ranlib.. " for ranlib in ${host_system_type}-ranlib ranlib do - $ar --version >/dev/null 2>&1 + $ranlib --version >/dev/null 2>&1 if [ $? -eq 0 ] ; then ranlib="$ranlib" ; break ; fi done if [ -n "$ranlib" ] ; then ------------------------------------------------------------------------ I modified the files as below. youngho.shin@aot-gsm:~/work/opengcd-test$ svn status [root(libdispatch), libBlocksRuntime, libkqueue and libpthreadworkqueue are the same] M makeconf/makeconf/installer.rb M makeconf/makeconf/baseproject.rb Thank you. Youngho. |
From: Mark H. <ma...@he...> - 2013-02-22 03:42:11
|
Hi, On Tue, Feb 19, 2013 at 11:38 PM, 김동범 <don...@lg...> wrote: > Hi, Mark.**** > > ** ** > > I tried to compile and build opengcd with arm-linux-gnueabi toolchain, so > I edited the configure script.**** > > Because I use opengcd in arm based linux, i.e. DTV.**** > > For compiling and building with arm-linux-gnueabi, not clang, I removed > –fblocks options and libBlocksRuntime part in configure script.**** > > I edited libkqueue and libpthread_workqueue also.**** > > ** ** > > I want to contribute this if possible.**** > > How can I contribute this to opengcd?**** > > ** > Thanks for sending the diffs! They will help me to understand what needs to be done. Instead of removing blocks from OpenGCD, could you just cross-compile it for ARM using clang? Here's an example of the CFLAGS you could try: http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-June/050970.html |
From: Mark H. <ma...@he...> - 2013-02-22 03:20:01
|
On Thu, Feb 21, 2013 at 1:20 AM, David Minor <Dav...@or...>wrote: > Hello Everyone,**** > > I just finished a comparative study of xdispatch , boost::asio, Intel TBB > and c++11 thread constructs. What I did was write multiple implementations > of an OpenCL based data-flow scheduler. As a result of this project I > discovered a few things missing in gcd. **** > > **1. **The ability to get the number of items currently waiting on > a queue. This is important for load-balancing. > **** > > **2. **A way to create thread-specific data. GCD has queue specific > data, but since a queue isn’t bound to a thread it’s not the same thing. I > found this to be important for efficiently doing task parallelism on GPU’s, > where the GPU driver itself can handle multiple streams, but those streams > need to be bound to threads.**** > > **3. **A way to limit the number of threads that a work item can be > dispatched on. This is also relevant to GPU operations, where (at least on > Nvidia) you want a thread per “real” GPU core and a stream (or OpenCL > queue) attached to each core.**** > > ** ** > > My question is whether it is worth my while to make these changes and try > to get them accepted and what is the procedure, forums etc. Where these > issues can be discussed. I don’t want to do this work unless there is some > sort of consensus on acceptance. Considering that Apple is driving GCD, I > don’t expect much of a hearing, but I imagine the xdispatch community would > be more receptive. Some of these issues (like queue size) can only be > resolved at the GCD level, but others could conceivably be implemented as > xdispatch features.**** > > OpenGCD and xdispatch are based on an old version of GCD from MacOS 10.6 (IIRC). There has been some development upstream related to integration with OpenCL: https://developer.apple.com/library/mac/#documentation/Performance/Conceptual/OpenCL_MacProgGuide/UsingGCDwOpenCL/UsingGCDwOpenCL.html#//apple_ref/doc/uid/TP40008312-CH13-SW1 I suggest you start by contacting the libdispatch mailing list and see what they say about these topics. Unfortunately, I have not done anything GPU-related and can't comment on what you are proposing. Regards, - Mark |
From: David M. <Dav...@or...> - 2013-02-21 06:33:07
|
Hello Everyone, I just finished a comparative study of xdispatch , boost::asio, Intel TBB and c++11 thread constructs. What I did was write multiple implementations of an OpenCL based data-flow scheduler. As a result of this project I discovered a few things missing in gcd. 1. The ability to get the number of items currently waiting on a queue. This is important for load-balancing. 2. A way to create thread-specific data. GCD has queue specific data, but since a queue isn't bound to a thread it's not the same thing. I found this to be important for efficiently doing task parallelism on GPU's, where the GPU driver itself can handle multiple streams, but those streams need to be bound to threads. 3. A way to limit the number of threads that a work item can be dispatched on. This is also relevant to GPU operations, where (at least on Nvidia) you want a thread per "real" GPU core and a stream (or OpenCL queue) attached to each core. My question is whether it is worth my while to make these changes and try to get them accepted and what is the procedure, forums etc. Where these issues can be discussed. I don't want to do this work unless there is some sort of consensus on acceptance. Considering that Apple is driving GCD, I don't expect much of a hearing, but I imagine the xdispatch community would be more receptive. Some of these issues (like queue size) can only be resolved at the GCD level, but others could conceivably be implemented as xdispatch features. Please advise, David Minor Orbotech |
From: 鄭偉凱 <a02...@gm...> - 2013-01-13 15:52:21
|
I try to use the opengcd-0.1-arm-linux-androideabi.tgz on android,but I encountered some difficulties. The following is the error message. ./obj/local/armeabi/dispatch.a(queue.o): In function `_dispatch_Block_copy': /tmp/opengcd-0.1/./libdispatch/src/queue.c:102: undefined reference to `_Block_copy' ./obj/local/armeabi/dispatch.a(queue.o): In function `_dispatch_call_block_and_release': /tmp/opengcd-0.1/./libdispatch/src/queue.c:115: undefined reference to `_Block_release' ./obj/local/armeabi/dispatch.a(queue.o): In function `_dispatch_call_block_and_release2': /tmp/opengcd-0.1/./libdispatch/src/queue.c:123: undefined reference to `_Block_release' ./obj/local/armeabi/dispatch.a(queue.o): In function `dispatch_barrier_sync': /tmp/opengcd-0.1/./libdispatch/src/queue.c:788: undefined reference to `_Block_copy' ./obj/local/armeabi/dispatch.a(queue.o): In function `_dispatch_queue_wakeup_global': /tmp/opengcd-0.1/./libdispatch/src/queue.c:1275: undefined reference to `pthread_workqueue_additem_np' ./obj/local/armeabi/dispatch.a(queue.o): In function `_dispatch_root_queues_init': /tmp/opengcd-0.1/./libdispatch/src/queue.c:1197: undefined reference to `pthread_workqueue_attr_init_np' /tmp/opengcd-0.1/./libdispatch/src/queue.c:1209: undefined reference to `pthread_workqueue_attr_setqueuepriority_np' /tmp/opengcd-0.1/./libdispatch/src/queue.c:1211: undefined reference to `pthread_workqueue_attr_setovercommit_np' /tmp/opengcd-0.1/./libdispatch/src/queue.c:1214: undefined reference to `pthread_workqueue_create_np' /tmp/opengcd-0.1/./libdispatch/src/queue.c:1243: undefined reference to `pthread_workqueue_attr_destroy_np' ./obj/local/armeabi/dispatch.a(queue_kevent.o): In function `_dispatch_update_kq': /tmp/opengcd-0.1/./libdispatch/src/queue_kevent.c:225: undefined reference to `kevent' ./obj/local/armeabi/dispatch.a(queue_kevent.o): In function `_dispatch_mgr_invoke': /tmp/opengcd-0.1/./libdispatch/src/queue_kevent.c:162: undefined reference to `kevent' ./obj/local/armeabi/dispatch.a(queue_kevent.o): In function `_dispatch_get_kq_init': /tmp/opengcd-0.1/./libdispatch/src/queue_kevent.c:42: undefined reference to `kqueue' /tmp/opengcd-0.1/./libdispatch/src/queue_kevent.c:51: undefined reference to `kevent' ./obj/local/armeabi/dispatch.a(source.o): In function `_dispatch_source_cancel_callout': /tmp/opengcd-0.1/./libdispatch/src/source.c:233: undefined reference to `_Block_release' /tmp/opengcd-0.1/./libdispatch/src/source.c:249: undefined reference to `_Block_release' ./obj/local/armeabi/dispatch.a(source.o): In function `_dispatch_source_set_event_handler2': /tmp/opengcd-0.1/./libdispatch/src/source.c:446: undefined reference to `_Block_release' ./obj/local/armeabi/dispatch.a(source.o): In function `_dispatch_source_set_event_handler_f': /tmp/opengcd-0.1/./libdispatch/src/source.c:471: undefined reference to `_Block_release' ./obj/local/armeabi/dispatch.a(source.o): In function `_dispatch_source_set_cancel_handler2': /tmp/opengcd-0.1/./libdispatch/src/source.c:497: undefined reference to `_Block_release' ./obj/local/armeabi/dispatch.a(source.o):/tmp/opengcd-0.1/./libdispatch/src/source.c:522: more undefined references to `_Block_release' follow clang: error: linker command failed with exit code 1 (use -v to see invocation) make: *** [obj/local/armeabi/libhellocpp.so] Error 1 What can I do to fix errors? Thank you. |
From: 鄭偉凱 <a02...@gm...> - 2013-01-13 15:45:12
|
I try to use the opengcd-0.1-arm-linux-androideabi.tgz on android,but I encountered some difficulties. The following is the error message. ./obj/local/armeabi/dispatch.a(queue.o): In function `_dispatch_Block_copy': /tmp/opengcd-0.1/./libdispatch/src/queue.c:102: undefined reference to `_Block_copy' ./obj/local/armeabi/dispatch.a(queue.o): In function `_dispatch_call_block_and_release': /tmp/opengcd-0.1/./libdispatch/src/queue.c:115: undefined reference to `_Block_release' ./obj/local/armeabi/dispatch.a(queue.o): In function `_dispatch_call_block_and_release2': /tmp/opengcd-0.1/./libdispatch/src/queue.c:123: undefined reference to `_Block_release' ./obj/local/armeabi/dispatch.a(queue.o): In function `dispatch_barrier_sync': /tmp/opengcd-0.1/./libdispatch/src/queue.c:788: undefined reference to `_Block_copy' ./obj/local/armeabi/dispatch.a(queue.o): In function `_dispatch_queue_wakeup_global': /tmp/opengcd-0.1/./libdispatch/src/queue.c:1275: undefined reference to `pthread_workqueue_additem_np' ./obj/local/armeabi/dispatch.a(queue.o): In function `_dispatch_root_queues_init': /tmp/opengcd-0.1/./libdispatch/src/queue.c:1197: undefined reference to `pthread_workqueue_attr_init_np' /tmp/opengcd-0.1/./libdispatch/src/queue.c:1209: undefined reference to `pthread_workqueue_attr_setqueuepriority_np' /tmp/opengcd-0.1/./libdispatch/src/queue.c:1211: undefined reference to `pthread_workqueue_attr_setovercommit_np' /tmp/opengcd-0.1/./libdispatch/src/queue.c:1214: undefined reference to `pthread_workqueue_create_np' /tmp/opengcd-0.1/./libdispatch/src/queue.c:1243: undefined reference to `pthread_workqueue_attr_destroy_np' ./obj/local/armeabi/dispatch.a(queue_kevent.o): In function `_dispatch_update_kq': /tmp/opengcd-0.1/./libdispatch/src/queue_kevent.c:225: undefined reference to `kevent' ./obj/local/armeabi/dispatch.a(queue_kevent.o): In function `_dispatch_mgr_invoke': /tmp/opengcd-0.1/./libdispatch/src/queue_kevent.c:162: undefined reference to `kevent' ./obj/local/armeabi/dispatch.a(queue_kevent.o): In function `_dispatch_get_kq_init': /tmp/opengcd-0.1/./libdispatch/src/queue_kevent.c:42: undefined reference to `kqueue' /tmp/opengcd-0.1/./libdispatch/src/queue_kevent.c:51: undefined reference to `kevent' ./obj/local/armeabi/dispatch.a(source.o): In function `_dispatch_source_cancel_callout': /tmp/opengcd-0.1/./libdispatch/src/source.c:233: undefined reference to `_Block_release' /tmp/opengcd-0.1/./libdispatch/src/source.c:249: undefined reference to `_Block_release' ./obj/local/armeabi/dispatch.a(source.o): In function `_dispatch_source_set_event_handler2': /tmp/opengcd-0.1/./libdispatch/src/source.c:446: undefined reference to `_Block_release' ./obj/local/armeabi/dispatch.a(source.o): In function `_dispatch_source_set_event_handler_f': /tmp/opengcd-0.1/./libdispatch/src/source.c:471: undefined reference to `_Block_release' ./obj/local/armeabi/dispatch.a(source.o): In function `_dispatch_source_set_cancel_handler2': /tmp/opengcd-0.1/./libdispatch/src/source.c:497: undefined reference to `_Block_release' ./obj/local/armeabi/dispatch.a(source.o):/tmp/opengcd-0.1/./libdispatch/src/source.c:522: more undefined references to `_Block_release' follow clang: error: linker command failed with exit code 1 (use -v to see invocation) make: *** [obj/local/armeabi/libhellocpp.so] Error 1 What can I do to fix errors? Thank you. |
From: Mark H. <ma...@he...> - 2012-12-15 02:29:02
|
The trunk is now buildable on Linux and can be cross-compiled for Android. All the unit tests pass (except for a known problem on Android). We are ready to create a version 0.2 release. Unfortunately the "make dist" target does not build a useful tarball. I'll work on Makconf this weekend to see if I can remedy this situation. - Mark |
From: Mark H. <ma...@he...> - 2012-12-14 02:49:12
|
As of r81, the trunk now builds on Android. The unit tests are failing, probably due to a difference between the config.h generated by Makeconf and the one generated by Autoconf. It shouldn't be hard to get this fixed, so I think we are very close to releasing OpenGCD v0.2 with support for the NDK's clang toolchain. |
From: 임정식 <jun...@lg...> - 2012-12-12 06:49:18
|
Hi Mark Though it doesn’t seem to have a great meaning, I fixed some warning messages when building libdispatch with opengcd-0.1-source.tgz Could you please give me your opinion about this and let me know how to apply this fix to OpenGCD source if it is appropriate? Thank you. |
From: 임정식 <jun...@lg...> - 2012-12-05 00:38:33
|
Hi Mark Thank you for your information Could you please explain how to build the latest OpenGCD in more detail? Thank you. From: Mark Heily [mailto:ma...@he...] Sent: Tuesday, December 04, 2012 12:55 PM To: ope...@li... Subject: [Opengcd-discuss] NDK r8c Good news: Android NDK r8c includes a Clang 3.1 toolchain out of the box. I have updated OpenGCD to work with the new toolchain, with the exception of libdispatch. Everything is working so far, so I am hopeful this will simplify the build process for Android. - Mark |
From: Mark H. <ma...@he...> - 2012-12-04 04:22:54
|
Good news: Android NDK r8c includes a Clang 3.1 toolchain out of the box. I have updated OpenGCD to work with the new toolchain, with the exception of libdispatch. Everything is working so far, so I am hopeful this will simplify the build process for Android. - Mark |