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!