[SCM] Samba Shared Repository - branch v3-3-test updated -
jra at samba.org
Wed Jan 28 22:35:13 GMT 2009
On Wed, Jan 28, 2009 at 11:00:31PM +0100, Stefan (metze) Metzmacher wrote:
> Jeremy Allison schrieb:
> > On Wed, Jan 28, 2009 at 09:21:34AM -0600, Volker Lendecke wrote:
> >> The branch, v3-3-test has been updated
> >> via 910cbc5d6e932fa8ed0066d407a40195b6629a37 (commit)
> >> via 3e9c89e81b2915ba1a2aac7b8d72a780f7f9b80e (commit)
> >> from a8a8dde5ac2b0c0b33e49af685650440469b287f (commit)
> >> http://gitweb.samba.org/?p=samba.git;a=shortlog;h=v3-3-test
> >> - Log -----------------------------------------------------------------
> >> commit 910cbc5d6e932fa8ed0066d407a40195b6629a37
> >> Author: Volker Lendecke <vl at samba.org>
> >> Date: Wed Jan 28 10:35:35 2009 +0100
> >> Avoid valgrind errors
> >> In event handlers, we might destroy other events that are pending in the lists.
> >> We can only run one event safely per select call.
> >> Yes, I've seen these valgrind errors :-)
> >> Jeremy, with ccdd921e61 you had checked in the change to run multiple events.
> >> Do you remember why it was necessary and could not be solved in a different
> >> way?
> > I'm coming to the conclusion that our events API needs an overhaul.
> > Returning a pointer to the internal event struct is inherently
> > dangerous due to these problems. What about returning a token
> > representing the event, and using a search mechanism internal
> > to the event library to translate between the token and the
> > desired pointer ?
> No, we just need to make sure we handle that event handlers may remove
> or add other events, it's just the samba3 specific code that didn't
> handle this and I think it's fine now.
I sent a patch to Volker to restore the multiple event behavior,
but we're still discussing if this is needed. Dealing with one
event per invocation looks safer so long as the code handles it.
The issue for me is if copies get made of event pointers. talloc_free's
can then be a problem. Event handles would be safer in the face of
logic errors (not that we should *have* any logic errors of course,
but that's not the issue :-).
> I may need to review how signal events are called, it's not that well
> tested as it's not used in samba4 by default. But the fd and timer
> events are pretty robust against this kind of problems.
Yeah, good work on the linux oplock events. I was planning to do
that work myself (to help understand the changes) but you got there
first :-). Then again I had some other issues to deal with this week :-).
More information about the samba-technical