[PATCH] Fix an abort in transaction_loop under transaction_loop_recovery test (bug 12580)
Volker Lendecke
Volker.Lendecke at SerNet.DE
Thu Feb 16 16:16:41 UTC 2017
On Wed, Feb 15, 2017 at 11:26:55AM +1100, Amitay Isaacs wrote:
> What's the best practice when using tevent_queue with tevent_req?
>
> comm_write_send/recv computation is used to send data to an fd. There can
> be multiple write requests occurring simultaneously, so comm_write_send
> uses a tevent_queue to serialize all those requests. However, what happens
> if tevent_req which is in the queue is freed? What's the best way to track
> the queue entry corresponding to that tevent_req?
>
> Here's an attempt to track tevent_req and corresponding tevent_queue_entry,
> so when tevent_req is free'd, the corresponding tevent_queue_entry also
> gets freed and the entry is removed from the queue.
Not answering directly:
There's code in lib/async_req that performs a very similar task:
writev_send. I would have to write a specific test case to see whether
writev_send is safe from the error you found in ctdb. One of the main
differences in lib/async_req is that we create a fresh tevent_fd when
a new write request comes in, whereas comm_write_send reuses the
existing one.
Question: Would it be worthwhile exploring to merge those two
functions, base one on top of the other? If I get it right the
outgoing fd event is only really necessary if the kernel buffer is
full. Is the overhead of tevent_add_fd really measurable? In theory I
would guess 99% of the time the kernel buffer should be empty, and if
we do a nonblocking write no tevent_fd should be necessary at all.
Volker
More information about the samba-technical
mailing list