From: Tom H. <th...@cy...> - 2004-08-04 17:57:31
|
In message <200...@cc...> Jeff Dike <jd...@ad...> wrote: > th...@cy... said: > > Even doing that (if it's still possible) is quite dangerous as that > > thread could accidentally damage valgrind's environment. > > So? It's also quite dangerous as that thread could damage another thread's > environment. That's the nature of multithreaded apps. The problem is that the virtual environment seen by a program running under valgrind may not be the same as the real environment - things like signal handlers, signal masks, resource limits and son. That might be confusing for the thread that isn't running under valgrind and might even lead to that thread damaging the process state. I'm not saying it will happen, just that it's something to beware of. > > That would imply that the newly created thread was left to run on the > > real CPU rather than the simulated CPU. If that's the case then I'm > > not that it is possible anymore - I know we had to take out the stuff > > that allowed valgrind to switch back to the real CPU after running a > > specified number of basic blocks because it could no longer be made to > > work. > > We're not talking about a thread switching back and forth between the real > CPU and the simulated one. We're talking about a thread being created on > the real CPU and staying there. It's still switch from the simulated CPU to the real CPU though - the thread of control arrives at the clone and then branches with one branch continuing on the real CPU and one on the simulated CPU. That sounds to me just the same (for the new thread) as the existing thread of control continuing on the real CPU. You probably really need Jeremy's thoughts on the matter - he's more up on this stuff and I think he was involved in dropping the support for switching back to the real CPU. Tom -- Tom Hughes (th...@cy...) Software Engineer, Cyberscience Corporation http://www.cyberscience.com/ |