Re: custom background thread and module sharing a data structure

Hi, > My point is that within a single process, multiple threads can service > requests that can end up firing your module code. If you only do process > locking you can still have more than 1 thread executing your module code at > the same time. > > Just a process level lock will *not* guarante

Re: custom background thread and module sharing a data structure

Andrej van der Zee wrote: Hi, Thanks for your comments. See below... Worker mpm is a multithreaded, multiprocess mpm. Multiple child processes host multiple worker threads that run your module code. If your module services 2 concurrent requests in 2 different threads in the same process and b

Re: post_config on reload

Hi, Register a function with the cleanup of the conf pool. The conf pool >> is destroyed prior to a restart/kill/reload. >> >> You have an example in the code I've sent you. >> >> S >> >> >> > Perfect answer! Unfortunately, the post_config is called twice on a > restart, and with different memor

Re: custom background thread and module sharing a data structure

Hi, Thanks for your comments. See below... Worker mpm is a multithreaded, multiprocess mpm. Multiple child processes > host multiple worker threads that run your module code. > > If your module services 2 concurrent requests in 2 different threads in the > same process and both the threads need t

Re: post_config on reload

Sorin Manolache wrote: On Fri, Mar 13, 2009 at 16:21, Andrej van der Zee wrote: Hi, Do not do this - a restart should be a restart, not a half of a restart. You should be reinitializing whatever you do on a restart as well as a start. That's the whole point. I have one phrase that

Re: custom background thread and module sharing a data structure

Andrej van der Zee wrote: Hi Saju, For the worker mpm, both cross thread and cross process protection will be needed. apr_proc_mutex.h family supplies cross-process protection, apr_thread_mutex.h provides cross thread protection. You "locking" method would be a wrapper method that first obtain

Re: post_config on reload

Hi, Do not do this - a restart should be a restart, not a half of a restart. > You should be reinitializing whatever you do on a restart as well as a > start. That's the whole point. > > I have one phrase that should illustrate why : memory leak. > > For example, if your extension creates anoth

Re: post_config on reload

On Fri, Mar 13, 2009 at 16:21, Andrej van der Zee wrote: > Hi, > > Do not do this -  a restart should be a restart, not a half of a restart. >>  You should be reinitializing whatever you do on a restart as well as a >> start.  That's the whole point. >> >> I have one phrase that should illustrate

Re: custom background thread and module sharing a data structure

Hi Saju, For the worker mpm, both cross thread and cross process protection will be > needed. apr_proc_mutex.h family supplies cross-process protection, > apr_thread_mutex.h provides cross thread protection. > > You "locking" method would be a wrapper method that first obtains a process > level lo

post_config on reload

Hi, I found this piece of code for dealing with the post_config issue (it is called twice, while I need to initialise my stuff only once): void *data; const char *userdata_key = "post_config_only_once_key"; apr_pool_userdata_get(&data, userdata_key, s->process->pool); if (!data) { apr