Re: [boost] Futures

Subject: Re: [boost] Futures
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-01-15 10:19:28

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/