On 15 Jan 2015 at 15:10, Andreas Schäfer wrote:
To be honest, C code only needs the ability to compose waits, that's the frustrating part because C++ is all up itself with no regard to others.
I realize the value of being able to call C++ functions from C code. I'm skeptical though about designing C++ libraries so that they can export features which simply don't exist in C, if that complicates the design.
Calling C++ code from C is straightforward enough, and isn't the hard part here. Well, especially if the C++ code is noexcept at least. The problem is rather like "future islands", except that all of C++ is a giant future island to C code.
For example, if a promise-future could toggle the signalled state of a file descriptor, that would enable C code to run a select() composure where the C code waits on "something to happen", which includes a C++ future becoming set.
Wouldn't it be an acceptable workaround to have a wrapper for futures, written in C++, which can signal a FD once the future is ready? Pulling such functionality into the API of C++ futures doesn't look clean for me, especially since there are loads of use cases where a context switch is prohibitively slow.
Another workaround would be to require users to compile the C function which needs to compose the waits with a C compiler.
Remember that almost certainly the C code is working with a set of libraries it does not own nor control e.g. the Python runtime. If the C code would like to sleep the process until something happens, right now you fire off worker threads which wait on each of the third party libraries and the sole purpose of the worker threads is to signal your unified wait composure implementation when the third party library unblocks. This sucks. I think the future.then() facility in the Concurrency TS at least allows C code to hook future state changes with some C callback, so for example it could write a byte to some fd to get a select() call to wake. The only real problem is the potential variance in when the continuation gets called, but I'd assume the programmer writing the C hook can figure that out. Again though, it's unfortunate there isn't a universal wait object in C also used by C++. That pthreads permit object of mine allows composure i.e. wait_for_all() and wait_for_any(), albeit with O(N) scaling unfortunately, but then at least C code could assemble a list of event states to watch for change and sleep until change occurs. You can of course do this with file descriptors, but as you mentioned that is very slow compared to a pure userspace wait object. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/