How to bind disruptor producer and process threads to specific CPU cores for easier management?

[ulnit]

So, it can ensure that the CPU cores of the machine can be allocated according to needs.

[nicholassm]

Hi,

Yes, absolutely!
Regarding the process thread is has been on the Main branch for a while but it hasn't been published yet. I'm going to publish that feature in version 0.3.0.

Regarding the producer threads, I recommend adding core_affinity = "0.8.0" and set the producer thread's affinity to e.g. core #3 by e.g.

let got_pinned = core_affinity::set_for_current(CoreId { id: 3 } );
if got_pinned {
    // Now pinned.
}

Kind regards,
Nicholas

[nicholassm]

Hi again,

Version 0.3.0 is out now. See how to pin the processing thread in the docs for the Builder#pin_processor_to_core method.
(However, as of writing it's number 207 in the docs.rs publish queue!)

Kind regards,
Nicholas

[ulnit]

Hi again,

Version 0.3.0 is out now. See how to pin the processing thread in the docs for the Builder#pin_processor_to_core method. (However, as of writing it's number 207 in the docs.rs publish queue!)

Kind regards, Nicholas

Okay, I will integrate version 0.3.0 into the project and see.

[ulnit]

set_for_current
There was an error in the program. The information is as follows:
“thread 'main' panicked at 'Could not pin processor thread 'processor' to CoreId { id: 0 }', /Users/sean/.cargo/registry/src/mirrors.ustc.edu.cn-61ef6e0cd06fb9b8/disruptor-0.3.0/src/consumer.rs:83:13”

The code is:
let disruptor_producer = Builder::new(1024*1024*4, factory, processor.clone(), BusySpin).pin_processor_to_core(id).create_with_single_producer(); disruptors.push(disruptor_producer);

[nicholassm]

What OS are you running on?
I've verified it works on Linux flavours but your mileage might vary on other OS'es. It could be e.g. permissioning that's in the way. Check out any open issues for the core-affinity lib.
And - in my opinion - Linux is the only one that counts for any low latency production workload. :-)
It's of course annoying if it doesn't work in your development environment.

Kind regards,
Nicholas

[ulnit]

What OS are you running on? I've verified it works on Linux flavours but your mileage might vary on other OS'es. It could be e.g. permissioning that's in the way. Check out any open issues for the core-affinity lib. And - in my opinion - Linux is the only one that counts for any low latency production workload. :-) It's of course annoying if it doesn't work in your development environment.

Kind regards, Nicholas
Thank you for your guidance, it can run on the Linux operating system now. However, my development environment is macOS. I was able to run the demo program separately using core_affinity = "0.8.1", but it didn't work with the disruptor library. I'm not sure if there are any other reasons because I am still a beginner in using the Rust language.

[ulnit]

What OS are you running on? I've verified it works on Linux flavours but your mileage might vary on other OS'es. It could be e.g. permissioning that's in the way. Check out any open issues for the core-affinity lib. And - in my opinion - Linux is the only one that counts for any low latency production workload. :-) It's of course annoying if it doesn't work in your development environment.

Kind regards, Nicholas

Another question，does the processor support batch event retrieval?

[nicholassm]

The current Disruptor version uses 0.8.0 of core-affinity so that is why. I'll try and update it to the newer version and see if it works on Mac as well.

Regarding supporting batch event retrieval: You can see that in the bool flag passed into the closure. If it's true the batch has ended - otherwise the next invocation of the closure will be part of the available batch of events. See also the docs.
(I don't know if you know how this works in the original Disruptor lib - this is exactly the same.)

Kind regards,
Nicholas

[nicholassm]

Hi again,

I've tried upgrading to 0.8.1 but no luck on my Macbook.
I've now opened an issue in the core-affinity repo.
Let's see what that brings.

Kind regards,
Nicholas

[nicholassm]

Hi again,

I've published version 0.4.0 where the Builder will no longer panic on e.g. Mac if there's a thread affinity error. Instead it will log on stderr. Give it a spin. :-)

Kind regards,
Nicholas