|
From: Julian S. <js...@ac...> - 2008-01-04 01:39:59
|
> > 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. Although the polling scheme has these 2 disadvantages, the other approaches involving signals and extra threads worry me. The signal/syscall/thread interactions are already a nightmare of complexity and I'm less than enthusiastic about messing with that stuff. At least the current Callgrind scheme localises its complexity in one place. The performance aspects are not a big deal, because we can make the scheduler polling-aware - let it decide when to poll, and, if the intervals get too close together, increase the scheduling quantum (or something similar) so as to limit the polling rate. The only real problem is the case where all client threads are sleeping. J |