Thanks, I wasn't sure if the docs were in sync with the source. Still, in that case I would have thought that only one of the 'listening' workers would have received the signal, when in fact it was somewhat unpredictable, and always more than one.
Regardless I would have expected the signal to keep firing for each file change/touch. I was doing this on Mac OS 10.6, just to try it out. The app will be deployed on RedHat 5.5. We can work around this, the signals would have been a rather sexy approach to the problem. I'm trying to avoid spawning a thread. -- Berndt Jung Sent with Sparrow On Tuesday, May 17, 2011 at 10:14 AM, Roberto De Ioris wrote: > > > Hi, > > > > I'm trying to use the add_file_monitor function to detect a change in an > > application config file. I put the following in my application: > > > > def init(): > > uwsgi.register_signal(99, 'workers', change_response) > > > The 'workers' kind of signal is not implemented. It fallback to the > default 'worker' or '' that will deliver the signal to the first available > worker. > > > > > uwsgi.add_file_monitor(99, '/Users/berndtj/Dev/uwsgi/message.txt') > > > > If I wrap the those calls in a function called from uwsgi.post_fork_hook, > > all workers register the signal, and all workers (and more receive the > > signal: > > > > Tu > > > > In all situations though, the signal is only sent the first time the file > > is changed. Subsequent changes do not trigger the signal. This seems > > like a bug, as the signal should fire on every change according to the > > docs. > > which OS ? > > > -- > Roberto De Ioris > http://unbit.it > _______________________________________________ > uWSGI mailing list > [email protected] > http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi >
_______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
