Hi, all. I checked out libkqueue (r119) and libdispatch (r174) and just naively attempted to build. libkqueue builds and passes it's test suite under gcc on Fedora 11 (x86 architecture, of course), libdispatch builds the library and part of the test suite but fails when it can't find arc4random(). (I gather this is expected.) Of the tests that build, several pass. Is this about what should happen at this stage in the porting effort? I gather that in the absence of the blocks compiler extension that functionally is just ripped out of the suite with the #ifdef __BLOCKS__ directives I see in the source? I'm just trying to understand the status of the port at this time and find out whether it's too soon to use it to write a toy program to explore the programming model. Dustin
Hi, Dustin Laurence schrieb:
Hi, all. I checked out libkqueue (r119) and libdispatch (r174) and just naively attempted to build. libkqueue builds and passes it's test suite under gcc on Fedora 11 (x86 architecture, of course), libdispatch builds the library and part of the test suite but fails when it can't find arc4random(). (I gather this is expected.) Of the tests that build, several pass. Is this about what should happen at this stage in the porting effort?
I gather that in the absence of the blocks compiler extension that functionally is just ripped out of the suite with the #ifdef __BLOCKS__ directives I see in the source? I'm just trying to understand the status of the port at this time and find out whether it's too soon to use it to write a toy program to explore the programming model.
This is the current state at the moment. If you have a look at my previous messages on the list, you'll find some patches I submitted that at least allow to compile libdispatch on Linux (including blocks support). However, most of the tests do not actually complete (aka. terminate) or even dispatch jobs correctly, so it's definitely too early to play with libdispatch on Linux. If you like to participate in fixing those issues, you're welcome. ciao, Mario
On 12/16/2009 06:13 AM, Mario Schwalbe wrote:
This is the current state at the moment. If you have a look at my previous messages on the list, you'll find some patches I submitted that at least allow to compile libdispatch on Linux (including blocks support).
With LLVM, I assume. I'm primarily interested in what can be done with vanilla GCC as shipped by Fedora or Debian. It's much harder to sell code that requires a custom compiler, for various technical and psychological reasons, and I might have serious uses for libdispatch down the road as the Linux port matures.
However, most of the tests do not actually complete (aka. terminate)
Actually, I think the majority of those that built completed and reported success. :-) Probably most of them hadn't built though. OTOH, dispatch_priority ate up so much CPU that it nearly shut down X and so it took a while to get it killed. :-) I didn't have the guts to run dispatch_priority2 and see what further mischief I could cause, as I had other things to get done. I should have told make to attempt to continue on errors...OK, it continues on to report that it can't find fgetln() either, another BSD-ism. If it's of interest I'll report precisely what built and what their results are, but I assume this is all normal right now and you don't need me to report results you already obtained yourself.
..or even dispatch jobs correctly, so it's definitely too early to play with libdispatch on Linux. If you like to participate in fixing those issues, you're welcome.
I don't know that I have the expertise to be much help at this stage, but I might get motivated to try at some point. My interest is in the cleanest concurrency programming abstractions, and GCD appears quite promising. On the other hand, my only practical needs are for vanilla GCC on vanilla linux, which is limiting in this case. In the mean time, let me ask a different question about something that requires less understanding of the implementation guts. With vanilla GCC, I assume there are no blocks. I also naively suspect that the blocks are used for a nice functional map/apply style of programming, so without them you'd probably be reduced to something like passing in C function pointers with manual management of what would have been the enclosing stack frame data. If that's true, then it would be convenient for C++ programmers to have a wrapper library to allow functors to replace the closures (they're basically manual closures anyway) and do some of the C-level chores. That seems like the most convenient C++ interface until vanilla GCC supplies the language extension you really want. Assuming all that is true, and that that is something the project would be interested in distributing as an optional C++ interface, I could probably write the wrapper as a way to get more familiar with the library and see how well it might meet my needs down the road. Dustin
participants (2)
-
Dustin Laurence
-
Mario Schwalbe