in reply to Configuration in threaded app

My advice is to not mix signals and threads, anywhere.

Personally, I would structure the worker threads to fetch messages from a central job queue, configuring them at startup. When reconfiguration becomes necessary, I would purge the current job queue (and maybe put the still pending jobs in the fresh job queue) and tell all current worker threads to quit. Then I'd fire up new worker threads with a fresh configuration and a fresh job queue.

Replies are listed 'Best First'.
Re^2: Configuration in threaded app
by Anonymous Monk on Aug 23, 2011 at 13:11 UTC
    What abount approach #1?

    BTW: What's wrong with threads & signals?
[reply]

      Why would you want to keep on accessing a shared structure? This will essentially create a central locked data structure that will make all threads block when one thread reads from the configuration.

      Signal handling vastly varies between the thread implementations, from catastrophic failures to behaving like processes. I would avoid signals instead of finding out what behaviour is prevalent with your Perl and your OS and just implement in-band messages through Thread::Queue. There rarely is a reason to tell a thread "Stop whatever you're doing" where you can't just kill the thread and configure a fresh thread.

[reply]

In Section Seekers of Perl Wisdom