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!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk