[dpdk-dev] [EXTERNAL] Re: [PATCH v6 06/10] eal: add thread lifetime management

[Dmitry Kozlyuk]

2021-04-29 21:31 (UTC+0000), Dmitry Malloy:
> Thread cancellation is a pain point. Emulating it properly is nearly
> impossible (without hooking into various OS calls which are supposed to be
> "cancellation points"). I do like the cancellation token idea, but I'm not
> sure how existing clients, who rely on existing phtread_cancel() semantic,
> will react to that - it will require a code re-write. 
>
> How about we defer fixing this to another follow-up change?

I'm strictly against accepting code with known severe bugs.

Alternative:

1. Don't add rte_thread_cancel() in public API.
2. Implement rte_thread_cancel() as internal API with cancellation tokens.
3. Rewrite DPDK code to use rte_thread_cancel().
4. For external users:
4.1. If their app is using pthread, they can use pthread backend for DPDK and
call pthread_cancel() directly.
4.2. If their app is not designed for pthread, they probably don't need
pthread_cancel() semantics and cancel threads another way.
4.3. If it's a brand new app, they will only use public API.

In 4.1 users need a pthread_t. In principle, they can call pthread_self()
from the thread to be cancelled and pass it to the thread that cancels. Or we
could provide API to get backend type and native handle. Since users have to
rewrite their code anyway to move from pthread to rte_thread, I'm for the
former approach. "Escape hatch" API would be very fragile.

P.S. Please avoid top-posting.