- libdispatch-dev - lists.macosforge.org

[PATCH 00/17] portability + chainsaw
by Paolo Bonzini 02 Nov '09

02 Nov '09

Here is my attempt at improving libdispatch's portability. Of course it's still a kevent-only show, but it should be easier now to implement an epoll-based (or even SIGIO+SIGALRM+poll-based) replacement. At least it makes more clear where the boundaries are between the kevent code and the rest. Because of the very precise requirements of libdispatch on kevent's semantics, it may be easier to go this way rather than implement kevent as a wrapper. I have no answer, and libnqkqueue is very interesting, but anyway these patches are quite safe. Here are them: - add .gitignore files - move __private_extern__ detection to an autoconf macro - move atomic builtin detections to separate autoconf macro - move blocks detection to separate autoconf macro - more precise detection of blocks Just configury. - split os_shims.h into separate files - remove compat/fd_copy.h - finish moving stuff into src/shims Unifying a bit the terminology, see individual comments. - portability After which the non-kqueue parts compile on Linux. - consolidate hashing of dispatch_kevent_t - move mach2nano/nano2mach from source.c to shims/ Two small cleanups. - extract source-type-specific initialization to per-type functions More completely developed later in the series. - abstract some mentions of ds->ds_dkev Also preparing for later. - extract kevent-specific parts of queue.c - almost completely separate kevent/source.c Moving code to new files without any change. You can check this with a command like diff -b <(git diff HEAD^^^! src/source.c | sed -n s/^-//p) <(git diff HEAD^^^! src/source_kevent.c | sed -n s/^+//p) - complete separation - remove last mention of struct kevent from "generic" code These finish the cleanup. Note: this was tested on FreeBSD only. HTH, Paolo

9 64

clang bugfix corrects libdispatch crashes on FreeBSD/amd64
by Robert Watson 01 Nov '09

01 Nov '09

Just an FYI for those who have been trying to use libdispatch on FreeBSD/amd64 with blocks: A bug in clang's __builtin_expect() was corrected in clang r85666, allowing it to be used with values/pointers > 32-bit. The bug didn't (visibly) affect Mac OS X as its malloc(3) does not (quickly) return pointers >32-bit, whereas the FreeBSD/amd64 malloc(3) uses them immediately on program start. If you've been seeing this segfault, try updating clang and see if that helps. Thanks to Ed Schouten to responding so rapidly to my bug report :-). If using the FreeBSD clang port: it hasn't yet been updated past that point (as of this morning), but you can force it to use the latest subversion revision by doing 'make BOOTSTRAP=yes makesum' before doing make/make install. Robert N M Watson Computer Laboratory University of Cambridge

1 0

[PATCH] simplify autogen.sh
by Paolo Bonzini 27 Oct '09

27 Oct '09

This is all that is needed, actually. --- autogen.sh | 6 +----- 1 files changed, 1 insertions(+), 5 deletions(-) diff --git a/autogen.sh b/autogen.sh index d4668c6..b83e6e7 100644 --- a/autogen.sh +++ b/autogen.sh @@ -2,9 +2,5 @@ # # # -libtoolize --copy --force -aclocal -autoheader -automake -a -c --foreign -autoconf +autoreconf -fvi -- 1.6.2.5

4 5

libkqueue website and SVN repository
by Mark Heily 24 Oct '09

24 Oct '09

I have created a simple website for libkqueue and imported the code into an SVN repository. The URI is: http://mark.heily.com/libkqueue/ To checkout the SVN repository, run the following command: svn checkout svn://mark.heily.com/libkqueue Regards, - Mark

1 0

libkqueue
by Mark Heily 19 Oct '09

19 Oct '09

After looking at the differences between kqueue(2) and libevent, I decided it would be best to write a very thin wrapper library to emulate kqueue on non-BSD platforms. I've gotten pretty far with the effort to port kqueue to Linux, and wanted to let everyone know that this is a work-in-progress. The working title of this effort is "libkqueue". If you are curious, you can download the libkqueue source code from here: http://mark.heily.com/src/ Currently, I have implemented the EVFILT_READ, EVFILT_WRITE, and EVFILT_SIGNAL filter types. I plan to implement EVFILT_VNODE using inotify, and EVFILT_TIMER using timerfds. I might have to implement EVFILT_PROC using a helper thread. After the Linux port is complete, I'll consider other Unixes such as OpenSolaris. I'm not a Windows developer, so if anyone wants to help with a Windows port, that would be great. It is my hope that the quality and completeness of libkqueue will soon be sufficient enough to be used with libdispatch. Regards, - Mark

3 3

portability patches
by Paolo Bonzini 17 Oct '09

17 Oct '09

Hi all, I managed to dissect libdispatch well enough that on Linux everything compiles except for two files including all the kqueue bits (which are extracted from queue.c and source.c). Here are the patches: Paolo Bonzini (13): split os_shims.h into separate files move __private_extern__ detection to an autoconf macro remove compat/fd_copy.h finish moving stuff into src/shims portability consolidate hashing of dispatch_kevent_t move mach2nano/nano2mach from source.c to shims/ extract source-type-specific initialization to per-type functions abstract some mentions of ds->ds_dkev extract kevent-specific parts of queue.c almost completely separate kevent/source.c complete separation All but the last three are relatively boring. Would these patches be interesting enough that I should dig up my PPC Mac? Do I have any hope to run libdispatch under Tiger? Paolo

2 2

GCD libdispatch w/Blocks support working on FreeBSD
by Robert Watson 26 Sep '09

26 Sep '09

Dear all: This is a quick update for those interested in the general portability of libdispatch, and perhaps specifically FreeBSD. With a bit of help from Jordan Hubbard, I now have libdispatch working with Blocks on FreeBSD. Jordan has put up a FreeBSD clang-devel package that includes Blocks parts and the C runtime bits here: http://static.macosforge.org/libdispatch/downloads/clang-devel.tgz I've updated the libdispatch build parts to detect and use Blocks when compiled with clang, and fixed a few nits in libdispatch that I ran into along the way (and one apparent clang bug). With Jordan's package as a starting point, Blocks pretty much "just worked", so I'm optimistic that people will be able to reproduce this on other platforms able to run the non-Blocks libdispatch without much difficulty. If you update to at least r45 of libdispatch, you should now be able to do: CC=clang ./configure --with-blocks-runtime=/usr/local/lib and get a libdispatch with Blocks support. The reason for the configure argument is that the current clang-devel package doesn't automatically add libBlocksRuntime dependency for binaries compiled with -fblocks. Once Blocks support shakes out a bit more in clang/FreeBSD, this should go away. I am able to run basic Blocks-based test tools with GCD on FreeBSD without difficulty. The FreeBSD port should be updated to reflect this shortly. Robert N M Watson Computer Laboratory University of Cambridge

1 0

Windows compatibility
by Vincent Bourdier 26 Sep '09

26 Sep '09

Hi everybody ! I just discover libdispatch, and I didn't found any information about the portability on other OS than MAC ... is it available on Windows ? Thanks. Regards, Vincent.

8 12

linux port
by Chris Pardy 25 Sep '09

25 Sep '09

Hello Everybody I'm Chris Pardy. I'm looking to compile libdispatch (userspace) on linux (fc 11). Is anybody else on the list working on this? 'Pardy

5 4

[PATCH] Add --enable-optimized and --disable-debug & set --march properly
by Bobby Powers 25 Sep '09

25 Sep '09

Hi folks, This patch cleans up the -march=i686 from src/Makefile.am, setting it in configure.ac if we're not on a 64-bit system. It also adds --enable-optimized and --disable-debug to the configure script, giving slightly more control over CFLAGS (and if you set CFLAGS as part of the configure arguments it overrides all these settings. I had a bit more work to split the headers off into their own directory, but I need to clean up the patchset. It applies with: patch -p1 <path/to/patch Let me know how it looks, in particular the detection of 64-bit is a bit hackish. yours, Bobby

5 5