[libdispatch-dev] Building on Linux

[Dustin Laurence]

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