r4943: Smplified the events handling code a lot. The first source of

complexity was that events didn't automatically cleanup
themselves. This was because the events code was written before we had
talloc destructors, so you needed to call event_remove_XX() to clean
the event out of the event lists from every piece of code that used
events. I have now added automatic event destructors, which in turn
allowed me to simplify a lot of the calling code.

The 2nd source of complexity was caused by the ref_count, which was
needed to cope with event handlers destroying events while handling
them, which meant the linked lists became invalid, so the ref_count ws
used to mark events for later destruction.

The new system is much simpler. I now have a ev->destruction_count,
which is incremented in all event destructors. The event dispatch code
checks for changes to this and handles it.
(This used to be commit a3c7417cfeab429ffb22d5546b205818f531a7b4)

1 files changed, 1 insertions, 3 deletions

diff --git a/source4/libcli/resolve/host.c b/source4/libcli/resolve/host.c
index 2cc0c1705f..b9aa1aa272 100644
--- a/source4/libcli/resolve/host.c
+++ b/source4/libcli/resolve/host.c
@@ -57,9 +57,6 @@ static int host_destructor(void *ptr)
 	if (state->child != (pid_t)-1) {
 		kill(state->child, SIGTERM);
 	}
-	if (state->fde) {
-		event_remove_fd(state->event_ctx, state->fde);
-	}
 	return 0;
 }
 
@@ -174,6 +171,7 @@ struct smbcli_composite *resolve_name_host_send(struct nbt_name *name,
 		close(fd[1]);
 		goto failed;
 	}
+	talloc_steal(state, state->fde);
 
 	/* signal handling in posix really sucks - doing this in a library
 	   affects the whole app, but what else to do?? */