|
From: Josef W. <Jos...@gm...> - 2008-01-04 01:09:35
|
On Friday 04 January 2008, Nicholas Nethercote wrote: > 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. Even more complex: "the file specifies the *name of a file* which regularly is polled by callgrind for existance, and with the command as content". Aside from that, yes, it is complex. I started with the file approach because it does not need any file descriptor open all the time. Descriptors are closed directly after each single action. This "design" still is from Valgrind 1.x days... > 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. Yes. But it does not feel like the right thing for interactive control. > But the no-response-when-sleeping > issue is bad. If we really can use a signal, this gets a non-issue (and also does not need the control thread). > > 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. Yes. > - 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. In principle, this looks similar to the file approach. Named pipes are persistant, and you need a way for cleanup in the case of a VG crash. Perhaps it is better to make the command sender responsible for creating the pipe, and valgrind checks for the existance under a defined name (such as your suggestion). Doesn't "read ... every so often" also have the sleep problem? We should add a signal to trigger the check. > - 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. With a signal, a dedicated control thread is not needed. Hmmm... Allowing network connections to control a valgrind tool is perhaps not the best thing (security issues come to mind). And unix domain sockets are similar to named pipes for the given task (?)... > - Shared memory. Seems like a bad idea. Not needed. Interactive commands should require only low bandwidth. [Shared memory IPC would be really good for sending chunks of events for further processing in another process]. > But I really don't know much about IPC, so others may have more informed > opinions. I am also not sure what's the best... Perhaps a combination of pipe and signal could work fine. Josef > > Nick > |