[PATCH] Fix an abort in transaction_loop under transaction_loop_recovery test (bug 12580)

[Amitay Isaacs]

On Fri, Feb 17, 2017 at 3:16 AM, Volker Lendecke <Volker.Lendecke at sernet.de>
wrote:

> 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.
>

When I was designing comm abstraction, I was thinking of ctdb daemon with
thousands of fds in the epoll set and trying to avoid adding/removing fd
for every read/write.  So far this code has only been used in the client
context where there is usually only a single fd to worry about.

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.
>

In the client context of course the overhead is going to be very small, but
in the server context this may become an issue.  But I don't have any hard
evidence to support this.

If there is a large chunk of data to be written to non-blocking fd with
writev(), will it not block to write the whole data since the operation
needs to be atomic? (I really need to test this.)

Amitay.