Re: [PATCH 2/2] Fix futex timeouts, handle futex error codes, and add mtxtimedlock, semtimedwait, and condtimedwait.

[Ori Bernstein <ori@xxxxxxxxxxxxxx>]

On Tue, 31 Jul 2018 23:44:37 -0700, iriri <iri@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

> Assuming you haven't merged this already I'm fine with tabling this patch for
> now and revisiting it in a week or two. 

There's no need to wait, just a bit of thought about exactly how/where it
would get used; things added to the standard libraries need to be carefully
designed, and it's often better to do nothing than to do the wrong thing.

> I think the non-mutex-bound condition variable is worth pursuing as a
> primitive, especially if it can have a dead simple and lightweight
> implementation as a one-member struct, but I'm not quite sure about the
> semantics yet.

Let's think a bit harder about the way we weant to write applications, collect
use cases, and then implement what it takes to support them. There are tons of
great approaches, and a lot of learning that I could stand to do on them.

I'd also like to take a look at what various other threading libraries and
utilities to, from Apple's GCD to Intel's TBB, and maybe a few others.

I've got some common use cases in mind, and I'm going to start spending
time looking at what various other programs do to solve their concurrency
problems.

> I'm not particularly attached to condtimedwait, but mtxtimedlock and
> semtimedwait are pretty useful, in my experience.
 
(Discussion ongoing on IRC)

> Also this would give me time to get my vm host running so I can actually test
> everything on every platform. :)

-- 
    Ori Bernstein