tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: cv_fdrestart()
> On Oct 14, 2023, at 6:38 AM, Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost> wrote:
>
>> Date: Fri, 13 Oct 2023 13:41:50 -0700
>> From: Jason Thorpe <thorpej%me.com@localhost>
>>
>>> On Oct 13, 2023, at 11:48 AM, Andrew Doran <ad%netbsd.org@localhost> wrote:
>>>
>>> Add cv_fdrestart() (better name suggestions welcome):
>>
>> Oooooof.
>
> Why do we need this at all?
Indeed.
> Condition variable semantics is standard, well-studied, and
> well-understood. This is a foundational API that essentially every
> kernel subsystem relies integrally on, and it strikes me as a mistake
> to tie it in with file descriptors or the ERESTART mechanism.
>
> I would ask that a controversial change like this be reverted until we
> have had substantive discussion giving a compelling reason to change
> such a foundational API to add custom, nonstandard semantics wiring it
> up to file descriptors and our ERESTART mechanism.
>
> We can just do
>
> foo->flags |= FOO_RESTART;
> cv_broadcast(cv);
>
> and then the corresponding wait logic can do
>
> if (foo->flags & FOO_RESTART)
> return ERESTART;
> cv_wait(cv);
> goto retry;
See also eventfd_wait().
My main objection was “putting fd-specific restart logic in condvars”. Of course it would be better to not pollute condvars at all.
-- thorpej
Home |
Main Index |
Thread Index |
Old Index