On Thu, 2017-01-05 at 13:19 -0800, Paul Eggert wrote: > On 01/05/2017 12:47 PM, Torvald Riegel wrote: > > If gnulib really wants to make concurrency simpler, than it should look > > at higher-level abstractions first. Especially parallelism. But maybe > > it should then just wait for what C++ specifies, or contribute to that > > I'm afraid this overestimates the amount of development resources we > have. Gnulib is contributed to only fitfully, and it mostly consists of > reasonably simple portability hacks. It has to be that way, otherwise > package developers won't understand and trust it. It's not a suitable > place to do concurrency research. > > Concurrency with shared memory is a hard problem, and the C++ (and C) > folks have messed it up for decades. Although they may get something > reasonable eventually, in the meantime Gnulib will probably prefer to > limp along with something on the safer side of the axis.
I'm not quite sure what you are trying to say. First, are you familiar with what C++ has put out recently (eg, parallel algorithms in the C++17 draft?). Are you familiar with the memory model introduced in C11 and C++11? Second, C and C++ are supposed to be close to the hardware. Do you dislike that? If not, what would you have done differently? (Besides trying to get something like the memory model specified much earlier?) I'd agree regarding the concurrency research, but I'd see that as reason to not try to deviate from the semantics and the overall design of the synchronization primitives that POSIX / C provide to you -- in particular if that becomes nontrivial. Is that what you wanted to say?
