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

[Zachary Turner]

The main benefit is just cleaner code.  And really it will only just be 1
instance, since it will be a singleton.  So instead of writing
Host::DoSoemthing() it would be Host::GetInstance()->DoSomething().

That being said, I have some other ideas as well.  I feel like maybe Host
just ended up being the default place to put any function which needed to
interface with the platform.  For example, I see  file-system stuff in
Host, process launching stuff, and more.  I'm currently thinking about
maybe separating the stuff in Host into different logical groups, and then
moving that functionality into their own Host-layer classes.  So we'd have
lldb_host::FileSystem, for example, which would contain the Readlink,
Unlink, etc functions.  And an lldb_host::ProcessLauncher interface, which
would support different ways of launching processes, with derived
implementations such as PosixSpawnProcessLauncher, ExecProcessLauncher,
ForkProcessLauncher, WindowsProcessLauncher, etc etc.  Then existing code
that launches processes could use these classes instead.

Thoughts?


On Tue, Aug 12, 2014 at 3:59 PM, Greg Clayton <gclayton at apple.com> wrote:

>
> > 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140812/b5cc4db0/attachment.html>