On 08/19, Roland McGrath wrote: > > > Wait. It doesn't break this. It only breaks -EALREADY contract. And > > I don't understand why this is bad. > > The -EALREADY contract lets you have a report_death callback that does all > your cleanup and then returns UTRACE_DETACH.
I think this is possible without the current -EALREADY contract. > To have that plan, you need a > way for an asynchronous detach attempt to be excluded once report_death has > begun, and for that asynchronous caller to know that's the situation. The problem is, with the current conract detach is never simple if you have report_death. You always have to synchronize with this callback. But see below. > It breaks the documented API. I am of course open to changing the API. > But we need to get completely clear on what the new range of plans we'll > support is, and make the documentation and the implementation match. Yes. I thought it makes sense to change the API and docs if we can improve things, before utrace is widely used. But OK, lets's forget about this. > > Why? What is the point? What makes UTRACE_EVENT(DEATH) so special? > > I do not see the logic at all. > > It is special because it is the last interesting event to a traditional > user such as ptrace. Hence it is attractive to write a report_death > callback that returns UTRACE_DETACH "spontaneously", i.e. without an > asynchronous caller (i.e. debugger thread) having requested the detach. Sure. And this is still possible. > > If ->report_death() does something which the caller of utrace_control() > > should know, then they should take care of synchronization anyway. > > With or without this patch, utrace_control(DEATH) can return 0 after > > ->report_death() was already called. > > If your engine's report_death always returns UTRACE_DETACH, then > utrace_control(UTRACE_DETACH) can never return 0 once report_death > is about to be called nor any time thereafter. I don't undestand this. OK, probably I missed something, this doesn't matter. > But, the current state of play from the broader perspective is that we > really have no idea about the future viability of the utrace API. I don't > think it makes a lot of sense to put a great deal of effort into perfecting > the corners of the API much further when we don't really have any good > reasons to think that this API will be the basis of anything that survives > in the long run. Yes. I have to agree, this is good point. So, lets forget about these changes, at least for now. > The current focus of work is your ugdb prototype. If some utrace changes > make it greatly easier to get that to kind-of-working status, then they are > worthwhile. No. I didn't think about ugdb at all. I'll find the workaround for ugdb. If nothing else, I can use utrace_engine_ops->release(). Or something else. > If it > works in practice but has disturbing robustness holes, it is OK to just > comment that loudly now and move on to the next battle, IMHO. OK, agreed. Oleg.
