|
From: Nicholas N. <nj...@cs...> - 2008-01-04 00:15:46
|
On Sat, 22 Dec 2007, Josef Weidendorfer wrote: >> But Andre's initial point is still valid -- a lot of people seem to find the >> callgrind_control stuff useful. It would be nice if we made it part of the >> core so that multiple tools would be able to use it. > > While I think this is a very good idea, we should use another technique; > actually, I am not very proud of how this stuff is implemented. > > Callgrind's interactive support is done by regular polling for the existance > of a given file from tool code (which is called from instrumentation). > > This is problematic in at least 2 aspects: > * Polling is wasting CPU cycles, and does a lot of system calls. > * It does not work at all when the client is sleeping. This is really bad. > > It would be better if VG could spawn a control thread and wait for command > connections e.g. by listening on a socket. The hook call into the tool > should be done in a serialized way to the client threads, to have a > consistent state and avoid any racy behavior. > > In Callgrind, to see whether a simulation is running, another temporary > file is created in /tmp, "callgrind.info.<pid>". callgrind_control searches > for such files, and checks via /proc/<pid>/maps that there really is such a > process running under valgrind. > The callgrind.info file specifies the exact file which has to be created to > send interactive commands to the given Callgrind run. > > I do not think this would be needed when a VG run could be contacted via > sockets, as these are global for a machine... So if I understand correctly: - Callgrind creates a file in /tmp - callgrind_control searches for such files and checks /proc/<pid>/maps for the process - the file specifies to callgrind what to do (?) That is a bit complex. Basically, this requires IPC (inter-process communication). Using files has one definite potential virtue: it's really simple and portable, if done carefully -- all OSes support files. But the no-response-when-sleeping issue is bad. Other possibilities: - Signals -- we already reserve the top two signals for Valgrind, so another is possible. But they're not very informative, so we'd need an auxiliary mechanism (eg. a file) to pass extra info. - Pipes. These seem good. I guess it would be like how signals are currently handled -- the Valgrind tool would be set up to read from the pipe, and every so often the core would check to see if any new input has come in on the pipe. I'm not sure how the Valgrind tool would know what the pipe's name is (assuming it's named). Maybe having a standard name like "valgrind-<pid>-pipe" or somesuch would work. - Sockets. I don't know much about them. Having to spawn a control thread sounds complicated, though. Our current one-thread-per-thread scheme is nice and stable, I'd be reluctant to lose that. - Shared memory. Seems like a bad idea. But I really don't know much about IPC, so others may have more informed opinions. Nick |