Closed guill-delacourt closed 1 year ago
As a side note, setting only ZMQ_THREAD_SCHED_POLICY to SCHED_OTHER and not setting ZMQ_THREAD_PRIORITY will result in a failure on the pthread_setschedparam call (causing an abort) if the first socket is created by a thread with a real-time priority. In that case, the pthread_setschedparam is using the priority of the current thread, which isn't compatible with a SCHED_OTHER policy.
Issue description
When configuring the ZeroMQ threads with ZMQ_THREAD_SCHED_POLICY set to SCHED_OTHER and ZMQ_THREAD_PRIORITY set to 0, I have noticed that ZeroMQ sets the "nice" value of the thread to the minimum value (-20). However, doing this requires different capabilities than from those needed to set real-time scheduling policies and priorities. Since the ZeroMQ threads are created by the thread creating the first socket, if this thread has a real-time policy and priority, there is no way to "downgrade" the ZeroMQ threads to "normal" threads when the user does not have the nice capabilities.
The documentation indicates that a nice call is done when ZMQ_THREAD_PRIORITY is set and ZMQ_THREAD_SCHED_POLICY is not a real-time policy. However, the value of "0" for the priority indicates that the user wants a "normal" thread, and thus should not trigger a call to nice, unlike setting a non-zero value.
Ideally, the ZMQ_THREAD_PRIORITY shouldn't be used to set a nice value. Another option should be introduced for this, as it would allow setting the actual value.
Environment
Minimal test code / Steps to reproduce the issue
What's the actual result? (include assertion message & call stack if applicable)
The execution aborts (src/thread.cpp:354) due to a failure in the nice call.
What's the expected result?
The execution should not abort, as it doesn't call nice.