On Mon, Apr 03, 2023 at 12:52:06PM +0200, David Marchand wrote:
> Hello Tyler,
>
> On Thu, Mar 2, 2023 at 9:52 AM David Marchand <david.march...@redhat.com>
> wrote:
> > On Mon, Feb 27, 2023 at 5:13 PM Gaëtan Rivet <gr...@u256.net> wrote:
> > > Ah ok, so if I understand correctly, DPDK would need to declare some
> > > '__rte_lockable rte_mutex' and associated functions for transparent
> > > support,
> > > to wrap above the pthread API.
> >
> > Yes, this is what I had in mind for the mid/long term but it was too
> > late for 23.03 after -rc1.
> >
> > The Windows porting effort will probably need this abstraction too as
> > we are trying to stop relying on the pthread API.
> > I don't see this item in Microsoft roadmap, though.
>
> Do you have an opinion on this topic?
Okay, trying to grok the question here. If the question is do we want to
introduce a mutex/condition variable and lock/unlock signal/wait
abstraction?
I would certainly like to see reduced conditional compilation that
applications have to perform for the platform features. I also really
would like to purge the remaining pthread_{mutex,condvar} shim since it
is unsightly.
With msvc I think we could probably achieve the same with C11 threads but
I haven't investigated feasability and said with no investigation older
glibc may not provide the optional feature.
In the absence of C11 threads we can provide an rte_ abstraction but I
don't think I can put it on the roadmap until basic msvc support is
stood up (a question of resource prioritization as always).
I could commit to looking at it once msvc and atomics changes are merged
the earliest possible time frame for that is the start of the 23.11
cycle. If that happens at decent velocity I could even see adding it to
23.11 roadmap.
For now if someone else decides to introduce an abstraction I would just
caution strongly not to remove __rte_experimental from any API added
until I get a chance to focus on it.
ty
>
> Thanks.
>
> --
> David Marchand
