Subject: Re: [boost] Futures
From: Andreas Schäfer (gentryx_at_[hidden])
Date: 2015-01-15 09:10:34
On 13:33 Thu 15 Jan , Niall Douglas 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
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
> 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.
> FYI the pthreads permit object I wrote has the optional facility to
> signal a fd when it goes signalled, so a permit object based future
> would be very useful to C code.
Again, this depends on the use case. In HPC the time a system call
takes is considered millennia. Consider the case when hardware is
programmed by mapping memory directly into the address space of a user
-- ========================================================== Andreas Schäfer HPC and Grid Computing Chair of Computer Science 3 Friedrich-Alexander-Universität Erlangen-Nürnberg, Germany +49 9131 85-27910 PGP/GPG key via keyserver http://www.libgeodecomp.org ========================================================== (\___/) (+'.'+) (")_(") This is Bunny. Copy and paste Bunny into your signature to help him gain world domination!