pqf wrote: > 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. > I'd suggest use a mutex until the point that a problem is seen in practice. I doubt that the mutex will show up in any profiling of a request using mod_fcgid.
Barry
