Boost logo

Boost :

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.


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at