Indeed persistency isn't necessary, although supported; you have a point. I see in CPAN the very promising threads-shared module - its .xs clearly proves the win32 support, and in addition it works in non-threaded environments - great suggestion - thank you -; | [reply] |
You're welcome. There are some other tricks for getting good thread performance with mod_perl, mostly to do with when you load things. If you need more help and suggestions, come visit us on the mod_perl list.
| [reply] |
Indeed.... thats why threads are used .... to facilitate sharing between threads....otherwise just fork. Fork and shared memory are an alternative to threads and threads::shared. There may be an advantage to using shared memory in threads, notably it is the fastest IPC out there; but there are glitches....like how would you control
simultaneous concurrent access to the mmap region from different threads? You are risking data corruption.
| [reply] |
threads:::shared offers a lock() method that is released outside of the {} scope where it is. To try -;
| [reply] |
Thanks, I've seen that. However, in my design processes in my head, I always prefer to keep thread shared variables read-only from the outside. In otherwords, one thread should not be able to change a variable in another thread, without the target thread knowing(or asking for it). This is better for security, and avoids all chances for a run away condition, where threads are all trying to lock and change a var at the same time....constantly looping....and having their change thwarted millisecs later by another thread. This requires you to have a thread that acts as a main controlller..... like a parent, keeping order among the child threads.
| [reply] |