2009/10/13 pqf <p...@mailtech.cn>: > Hi, all > I am Ryan Pan, who wrote the first version of mod_fcgid. > While I uesd mod_fastcgi(not mod_fcgid), one issue that bother me is: while > a fastcgi process(created by mod_fastcgi's process manager process)in a dead > loop, no one is respond to kick it out. So from time to time, some fastcgi > processes would eat up the system cpu resource. > So while I wrote mod_fcgid, I create a block of share memory to store the > fastcgi process pipe path and pid, then httpd can search this share memory to > get the an idle fastcgi process, and once the communication timout(which > usually mean the fastcgi process deadly running), httpd will kick out this > "corrupt" process. > However there is a new problem now, every time httpd search this share > memory, it will have to get a global mutex, which is a combination of process > lock an thread lock, is it(a mutex lock for search a free node in a node > list) too heavy? Maybe spin lock on share memory is a good idea in this case? > But spin lock is system dependented, and apr library doesn't have this > interface. > I thought about this idea since I wrote mod_fcgid, but I am not sure whether > it is a good idea, so any advice from you guys will be highly appreciated.
The thought of a pure spin lock for interruptible code makes me nervous (what if you lose the CPU holding the lock; other threads/processes that need it waste their timeslice until you finish; thread priorities could help, but not across processes), but I don't have the right experience in this area. The easy answer: Crank up the load until the current implementation causes a real performance problem, then experiment with spin locks at the same load ;) Stray thoughts: maybe increasing the granularity of the lock could help (multiple busy lists with the inode used as a hash to get to the proper busy list) different mutexes for different lists (but the usage of some lists may be so simple that it isn't worth dropping the first mutex then getting another one) maybe use compare-swap or compare-double-swap as appropriate for some lists (e.g., handler thread adds to error list using atomic operation, not holding mutex; PM removes entire error list using atomic operation without getting global mutex, then processes one by one)
