[Cubicweb] Pyramid_cubicweb & pyramid cube - release soon, need review

Christophe de Vienne christophe at unlish.com
Fri Sep 19 15:47:42 CEST 2014

Le 19/09/2014 15:41, Denis Laxalde a écrit :
> Christophe de Vienne a écrit :
>> Le 19/09/2014 15:04, Denis Laxalde a écrit :
>>> Christophe de Vienne a écrit :
>>>> Why better ? Because it separates the auto-reloading from the debug
>>>> mode. More importantly, instead of using repo.reload_if_needed() on a
>>>> cube source file change, it completely restart immediately the process
>>>> if _any_ module, the interpreter or the configuration file changes.
>>> Why is this actually better to restart the whole process?
>> - It works with any change to any source file, including configuration
>> files -> no more server running on old sources because we are editing a
>> file which is outside the registry scope.
>> - It allow to drop all the 'reload' specific code from CW and makes it
>> simpler, hence easier to maintain and more solid.
>> Basically, I think a partial reload like CW has today is impossible to
>> make right. It will work in some cases, at a cost, but will never handle
>> all changes.
>>> In practice, I've got into troubles with looping tasks running in the
>>> middle of this "hard" reload.
>> They should be restarted as well.
>> What kind of trouble did you have ?
> The problem seems to be that they are not properly stopped, 
> apparently. So the reload does not even occur. I'm talking about 
> update-feeds looping task for instance.

So it is a bug. Is repo.shutdown() supposed to stop the looping tasks ? 
if not we need to add a few lines to stop them.

> I just wonder if os.kill is the proper thing to do.

It is the only way I found to auto-raise SystemExit in another thread 
than the monitoring one (sys.exit() wont work).
What is possible is that in some cases the signal is handled by the 
wrong thread, leading to the server not to stop properly.


More information about the Cubicweb mailing list