On 2/23/23 4:19 PM, Richard Cochran wrote:
On Thu, Feb 23, 2023 at 12:56:34PM -0800, Matt Corallo wrote:
There's two separate questions here - multiple readers receiving the same
data, and multiple readers receiving data exclusively about one channel.
I'd imagine the second is (much?) easier to implement, whereas the first is a
bunch of complexity.
This second idea would require a new API, so that user could select a
particular channel.
First idea would only change kernel behavior without changing the API.
Fair point. I figured a new IOCTL to filter was a lighter lift, even if a bunch of boilerplate to
define it.
I'm happy to take a crack at something to get the ball rolling, though not this week. I'm sure I
could copy+paste to make a new IOCTL work, but adding relevant queue limiting means I have to go
read much more kernel code to figure out which datastructures already exist there :).
It sounds like I should go replace the extts queue with a circular buffer, have every reader socket
store an index in the buffer, and new sockets read only futures pulses? I assume a new pulse already
wakes all select()ers on the sockets so nothing would need to change there. Is there some existing
code somewhere I should crib off of or just run and see where I get?
Thanks,
Matt
--
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe"
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the
subject.
Trouble? Email listmas...@chrony.tuxfamily.org.
