Hacker News Reader

Comment by leonatan | Hacker News Reader

Wouldn't libdispatch be a much better option if you don't mind Apple's blocks extension to the C language?

My understanding is that libdispatch is not a replacement for go's concurrency. With libdispatch each block (closure) that you dispatch runs on a given thread, if that block stalls for any reason then your thread is blocked. So even with a few blocked blocks (heh) your system could be stalled which is not the case with go where you can have millions of goroutines that are blocked.

libdispatch is more than just programs submitting blocks to queues – dispatch sources and event handlers can handle channels of asynchronous input as well.

I forgot about that part of libdispatch. You still can't do synchronous IO but you can use libdispatch semaphores, wait on a queue, etc. and that should not block the thread, right?

The docs offer different kinds of sources for automatically enqueueing blocks:

     #define DISPATCH_SOURCE_TYPE_DATA_ADD 
     #define DISPATCH_SOURCE_TYPE_DATA_OR 
     #define DISPATCH_SOURCE_TYPE_MACH_RECV 
     #define DISPATCH_SOURCE_TYPE_MACH_SEND 
     #define DISPATCH_SOURCE_TYPE_PROC 
     #define DISPATCH_SOURCE_TYPE_READ 
     #define DISPATCH_SOURCE_TYPE_SIGNAL 
     #define DISPATCH_SOURCE_TYPE_TIMER 
     #define DISPATCH_SOURCE_TYPE_VNODE 
     #define DISPATCH_SOURCE_TYPE_WRITE 
     #define DISPATCH_SOURCE_TYPE_MEMORYPRESSURE

I've built systems with libdispatch and blocks. I found it much nicer than traditional C style non-blocking IO or typical pthreads, both of which I have also done.

• You don't need to use blocks, there are function callback versions of the calls available, but blocks are nicer.

• There are asynchronous IO routines, that covers most of your stalls.

• Go probably stalls threads on page faults, as does libdispatch.

You can read about the Linux port of libdispatch at https://github.com/nickhutchinson/libdispatch

It looks like the Linux port of libdispatch uses OS threads through pthreads, so it's not a candidate for the user space light-weight threads needed for efficient CSP.

I'm fairly certain that is just to get the worker pool. The blocks on the queue don't each get a thread.

Reply on news.ycombinator.com