On 05/16, Denys Vlasenko wrote: > > On 05/16/2012 11:48 AM, Dmitry V. Levin wrote: >>> >>> One solution is to run waitpid() in a loop until it returns 0 "no more >>> tracees >>> to wait", then handle them all. It was NAKed a few years ago. >> >> It would be nice to have a look at that discussion. Do you have a >> reference? What was the rationale that time? > > I guess Roland saw it as "ugly" and "trying to work around ptrace API > which is a hopelessly bad API anyway".
It is indeed ugly and hopeless. But perhaps Roland hoped we can have something new. Now that utrace is dead, unlikely this is possible. > On the technical note, it adds additional waitpid call per every > syscall entry/exit, and serializes strace even more: instead of > servicing and restarting a thread as fast as we can, we collect > other threads - keeping ready threads stuck a bit longer. But what else we can do to fix the problem? (lets not discuss the vectorized do_wait right now ;) Imho, you should reconsider your patch. > I looked into in and _maybe_ signalfd may help us noticeably. unlikely, because > for one, some SIGCHLDs can be lost. yes, SIGCHLD doesn't queue. Oleg. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
