[compiler-rt] [compiler-rt][rtsan] sched cpu affinity for linux interception. (PR #124194)

[via llvm-commits]

davidtrevelyan wrote:

> This may fall into the "yes it is real-time-unsafe, but people do it when they are setting up so it is probably fine?"
> 
> For instance, to promote something to a real-time thread, or depromote it to a normal thread you use the call `pthread_setschedparam`, which you call from the thread that you want promoted.
> 
> I believe at least on mac, they recommend you depromote a real-time thread before you join it, calling anything else undefined.
> 
> So if a user calls these functions, they are technically interacting with the kernel, which is RT-unsafe, however, you must do it to get a rt-thread. This presents a kind of chicken-egg thing.
> 
> My personal feelings are that we should NOT intercept these calls, as I would be annoyed as a user to have to suppress them or ignore them.
> 
> Anyone else have any thoughts?

@cjappl Nice question and thanks for raising it! 

I appreciate that manipulating scheduler parameters is a normal thing to want to do in real-time programming, but I wanted to ask if there's a use case where the user would actually want to change the scheduling parameters from within their hot path algorithm (i.e. inside a `[[nonblocking]]` function). I understand that the real-time thread entrypoint functions will need to do this parameter manipulation - but this entrypoint can be different to the real-time algorithm entrypoint. Here's what I mean:

```cpp

void real_time_algorithm() [[clang::nonblocking]]
{
    while(should_continue)
        /* Do the actual real-time processing */
}

void real_time_thread_setup()
{
    promote_priority();
    /* Do resource allocation, etc. */
}

void real_time_thread_teardown()
{
    demote_priority();
}

void real_time_thread_entrypoint()
{
    real_time_thread_setup(); // not nonblocking
    real_time_algorithm(); // nonblocking
    real_time_thread_teardown(); // not nonblocking
}

auto real_time_thread = std::thread(real_time_thread_entrypoint);
```

If there's a common use case for manipulating these params inside the hot path functions then let's consider not intercepting - but if this is unusual then I think I would prefer to intercept. IMHO the false negative case is less concerning than the false positive case.

https://github.com/llvm/llvm-project/pull/124194