Note pre fetch and non temporal instructions really help with this.. I'm not deeply familiar with Disruptor, but I believe that it uses bounded >> queues. My general feeling thus far is that, as the general 'go-to' channel >> type, people should not be using bounded queues that block the sender when >> full because of the potential for unexpected deadlocks. I could be >> convinced otherwise though if it's just not possible to have reasonably >> fast unbounded channels. Note that I don't think it's critical for the >> general-purpose channel to be as fast as possible - it's more important to >> be convenient. >> > Rust tasks however are more than a GP channel .. they are your parralelism and saying they should be convenient is the same in the parralel world of saying your method callls should be convenient rather than fast - they need to be both with little compromise. It will be a major bottle neck to using independent task based components.
Note you dont need to stop the sender if the queue is full , what can do is write the messages to a buffer in the senders memory when the queue is full and continue running , you can then make a decision of how big that should be based on memory pressure ( you can persist part of the queue even ( maybe force paging) , causing a disk acces which the thread will wait for) etc.. Lockless , non blocking async IPC is possible ( so its possible with rust tasks) though its an area of little research . The key is the sender must either slow , have sufficient memory to handle all requests up till the point it stops running waiting for something else or persist some of that. Expanding queues are possible and help reduce memory but need carefull scheduling. ( obvious way is stop both , create a new queue and copy the data accross) . The worst case is probably a logger / printf service we have all experienced apps slowing to write to disk / console ,in this case they would not but it comes at the cost of memory . Ben
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
