> On Oct 24, 2014, at 3:38 PM, Zachary Turner <ztur...@google.com> wrote: > > What is the monitor_signals variable supposed to represent? Windows doesn't > have signals, so maybe I can just ignore this variable.
You can ignore this for windows. The typical way to monitor a child process is to call waitpid() which will tell you about signals and exit status. Is there no way to communicate anything between a process via the handle other than the process exiting? > Looking through the code, it seems like even MacOSX doesn't use this, and > just always sets it to false, and the only place this is ever set to true is > in Linux and FreeBSD. Maybe Todd knows? (I don't have his email new > address, but maybe you can +cc him on this email if you don't know the > answer). We are just exposing a feature that people launching subprocesses really might need. People can use signals to communicate between processes, so our host layer needs to include this. Another approach would be to return a launch error if anyone requests monitoring signals on windows. > > I kind of feel like the code would be clearer if ProcessMonitor were an > abstract interface in Host We don't use ProcessMonitor on MacOSX. > then DefaultWindowsProcessMonitor could do what it needs to do, > DefaultPosixProcessMonitor could do what it needs to do, ProcessLaunchInfo > could just have a pointer to a ProcessMonitor instead of both a callback and > a baton, it would be easier to chain callbacks like this because the class > could store a list of callbacks instead of just 1, and this monitor_signals > flag could be a member variable of LinuxProcessMonitor so that other > platforms wouldn't have to worry about dubiously ignoring it. Anyway, I've > had enough refactoring for a while, just thinking out loud. I would prefer to avoid this and just have you ignore or return an error if this flag is set. Reasons being, ProcessMonitor is only used by linux and doesn't really need to be in LLDB anymore. We really should be switching over to using lldb-gdbserver (it would be great if windows did this) so we get remote debugging for all platforms. Greg _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
