thread_policy_set not supported for M series chips

[Lovely-XPP]

Is there an already existing issue for this?

• I have searched the existing issues

Expected behavior

Example can nomally run.

Current behavior

After running the example, no response.

Steps to reproduce

Directly complime and the examples and they can not run.

Fast DDS version/commit

3.1.0

Platform/Architecture

Other. Please specify in Additional context section.

Transport layer

Default configuration, UDPv4 & SHM, TCPv4

Additional context

Platform: MacOS 15.2 Arm 64

thread_policy_set not supported for M series chips yet, therefore the function return 46 (KERN_NOT_SUPPORTED), then run into EPROSIMA_LOG_ERROR and stuck.

My temporary solution: if (0 != result) -> if (KERN_SUCCESS != result && result != KERN_NOT_SUPPORTED)

Refrences:

• Example cannot work #5145
• https://forums.developer.apple.com/forums/thread/699925

XML configuration file

No response

Relevant log output

No response

Network traffic capture

No response

[EugenioCollado]

Hi @Lovely-XPP,

The KERN_NOT_SUPPORTED (46) error from thread_policy_set() is expected since this function isn’t supported on the platform. The log is meant to inform about this limitation, and aside from not setting the thread's affinity, it shouldn’t cause any issues.

Could you clarify where exactly you’re getting stuck? Is it the log itself, or something else? Any additional details would help us better understand the problem and assist you further.

If support for this platform is critical for your use case, feel free to reach out so we can explore possible solutions or adaptations.

[Lovely-XPP]

Thanks, I debug again and find what exactly happens. eprosima::create_thread use a log module needed to creat a thread by eprosima::create_thread, this will cause a loop recursive call then cause the stuck.

Here is the full stacks.

if (KERN_SUCCESS != result)
        {
            EPROSIMA_LOG_ERROR(SYSTEM, "Problem to set affinity of thread with id [" << self_tid << "," << thread_name << "] to value " << affinity << ". Error '" << strerror(
                        result) << "'");
        }

if KERN_SUCCESS != result, then it will come to EPROSIMA_LOG_ERROR.

eprosima::configure_current_thread_affinity();
-> Call EPROSIMA_LOG_ERROR(); (src/cpp/utils/threading/threading_osx.ipp: Line 139)
-> Call EPROSIMA_LOG_ERROR_IMPL_(); (include/fastdds/dds/log/Log.hpp: Line 45)
-> Call eprosima::fastdds::dds::Log::QueueLog(); (include/fastdds/dds/log/Log.hpp: Line 294)
-> Call eprosima::fastdds::dds::detail::LogResources::QueueLog(); (src/cpp/fastdds/log/Log.cpp: Line 453)
-> Call eprosima::fastdds::dds::detail::LogResources::StartThread(); (src/cpp/fastdds/log/Log.cpp: Line 253)
-> Call eprosima::create_thread(); (src/cpp/fastdds/log/Log.cpp: Line 301)
-> Call eprosima::apply_thread_settings_to_current_thread(); (src/cpp/utils/threading/threading.hpp: Line 108)
-> Call eprosima::configure_current_thread_affinity(); (src/cpp/utils/threading/threading_osx.ipp: Line 152)

Then it will cause a loop recursive call for configure_current_thread_affinity() then cause the stuck.

Therefore, from the creation process of the thead, we can know the functions listed below may not use the log module:

• set_name_to_current_thread
• apply_thread_settings_to_current_thread
• configure_current_thread_scheduler
• configure_current_thread_affinity

[MiguelCompany]

We could check for the thread_name to be different from dds.log before calling EPROSIMA_LOG_ERROR