search

zeromq / libzmq

ZeroMQ core engine in C++, implements ZMTP/3.1
https://www.zeromq.org
Mozilla Public License 2.0
9.62k stars 2.35k forks source link

Setting ZMQ_THREAD_PRIORITY to 0 shouldn't nice the threads. #4512

Closed guill-delacourt closed 1 year ago

guill-delacourt commented 1 year ago

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

  1. Create a ZeroMQ context with a user that do not have the rights to set negative nice values.
  2. Set the option ZMQ_THREAD_SCHED_POLICY to SCHED_OTHER on the context.
  3. Set the option ZMQ_THREAD_PRIORITY to 0 on the context.
  4. Create a socket.

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.

guill-delacourt commented 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.

bluca commented 1 year ago

https://github.com/zeromq/libzmq/pull/4558