[qmtest] Proposal: modules reload

[Vladimir Prus]

Mark Mitchell wrote:
> > > I've thought about this in the past and never came to a definite
> > > conclusion.  On the one hand, reloading the modules *should* work, but
> > > I'm never sure it will always leave things in a consistent state. 
> > > (What if there is global data in those modules, or data elsewhere that
> > > has class types where the classes are defined in those modules?)
> >
> > Is that really possible? I though that tests/resources are short-lived
> > entities: i.e. they are loaded, run and leave only annotations behind.
> > Are test/resources instances stored anywhere?
>
> No, test/resources are never stored, presently, and that is by design:
> they might be big expensive objects.  However, it's possible that a
> database implementation might cache them, and sometime we'd like QMTest
> to be able to serve multiple test runs concurrently, so it might happen
> someday.
>
> It would probably be OK to do what you suggest; we could always do some
> kind of synchronization later, if required.

I'll take a stab on it, then. The biggest advantage over complete restart, 
IMO, will be that  you don't loose already generated results. 

(Don't expect any patches sooner than a week, though)

> > > Maybe a good place to start would be a "Restart" command on the QMTest
> > > file menu that would just shut down QMTest, and restart it, on the same
> > > port?
> >
> > That would be good for use cases you mention, but I have no idea how to
> > imlement this. Do you mean that a QMTestServer instance is restarted,
> > or entire qmtest script, or...
>
> The easiest thing is probably to restart the whole script; do a re-exec
> of the main Python script, which will flush all the modules and such.

Then the main Python script would have to return special value (e.g. 2) 
meaning "restart me" and we must hope that brower won't timeout before new 
QMTest instance is started. Seems plausible, but less important for me.

- Volodya