[lldb-dev] Would Host be better off as a non-static?

[Greg Clayton]

> On Aug 11, 2014, at 11:27 AM, Zachary Turner <zturner at google.com> wrote:
> 
> Currently Host is implemented as a static class with lots of ifdefs to define different versions of methods depending on the OS and platform.
> 
> Has anyone ever thought about turning this into a a singleton that returns an actual instance of a class?  This would provide a number of advantages, such as:
> 
> 1) Cleaner code.  You could use interfaces and inheritance to clearly define the common behavior of a Host, and allow each particular host to define its own platform specific functionality in derived implementations.
> 
> 2) More flexibility for supporting non-trivial platform differences.  As a quick example, currently launching a new process starts a monitoring thread, and passes data through type-erased batons and the like.  This might not necessarily be an appropriate model for all platforms.  Maybe I'd like to use one thread which I simply re-use for many different things, only one of which is monitoring processes.
> 
> 3) Member data.  Say you launch 10 processes.  It would be useful if there were just handles to all 10 processes sitting in an easily accessible location (at least for Windows anyway, this would be useful).  If there were a WindowsHost class, I could just have a list of HANDLE items in my class.
> 
> I'm sure there are many more benefits to doing so.
> 
> I'm still going over the class implementation, but I wanted to throw this out there for discussion.  Let's say I did want to go forward with this refactor though.  Anything I should keep in mind that isn't totally obvious?

Nothing has required state up to this point. You can always implement the windows stuff using this new class and see how it goes. Just use your singleton in any windows specific parts of the Host layer and we can see if it would be a good model for everyone. I would rather not require people to create a class instance if there is no real benefit, but I am open to hearing the reasons we might want such a thing.

Greg