Yes, but no allocation is even better than on-demand allocation, if you can
get away with it.
> I am OK with only supplying semaphores and rwlocks, if there is a general consent
> about it. Nevertheless, I think the multiqueue approach is somewhat more elegant
> and expandable.
Well, it's pretty easy to allow other values than -1/1 later as required.
I don't think the switch() overhead will be measurable for the first dozen
lock types 8).
> > > (h) how do you deal with signals ? E.g. SIGIO or something like it.
> >
> > They're interruptible, so you'll get -ERESTARTSYS. Should be fine.
> >
>
> That's what I did too, but some folks pointed out they might want to
> interrupt a waking task, so that it can get back into user space and
> fail with EAGAIN or so and do not automatically restart the syscall.
Sorry, my bad. I use -EINTR, so they don't get restarted, for exactly that
reason (eg. implementing timeouts on mutexes).
Cheers!
Rusty.
-- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/