Subject: Re: [boost] Futures
From: Andreas Schäfer (gentryx_at_[hidden])
Date: 2015-01-15 09:10:34
Hey Niall,
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
> 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.
> 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
level program.
Cheers
-Andreas
--
==========================================================
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!