[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