Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Killing an ISAPI thread. »

Killing an ISAPI thread.

php.internals

Richard Quadling

19 years ago
Hi. Running PHP via ISAPI on Sambar Server. I have a script which is allowed to take a long time. The user has an Abort option and via clever use of sessions, the script can be terminated. All fine. Sometimes, the user is too dumb to abort it when it has to do a LOT more work than they expect. In looking at the server threads, I see many of these scripts loaded, all doing their job correctly but without ever being able to send there details anywhere. I understand that I can't just terminate the PHP isapi.dll as that would bugger up the server, but does PHP have a mechanism by which a thread that it is looking after can be terminated by the server making a call to the isapi.dll. I was thinking that if the max_exec_time could be "manipulated" externally for a single thread within the dll, then the engine would suddenly realise it had taken too long and would terminate. Ideas? Regards, Richard Quadling.
-- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!"

Richard Lynch

19 years ago
On Wed, April 25, 2007 10:21 am, Richard Quadling wrote:
> Running PHP via ISAPI on Sambar Server. > > I have a script which is allowed to take a long time. > > The user has an Abort option and via clever use of sessions, the > script can be terminated.
[This answer probably belongs on php-general, but does not directly address the apropos question.] I suspect that you may want to do some serious browser-compatibility testing here... It's possible that the "stupid" users are the ones using a browser in which your Abort process simply doesn't work. You might also want to consider converting the whole thing over to a "job" oriented model. Users submit "jobs" and they are processed, perhaps piece-meal, until finished. Once you have it "job" oriented, it gets a lot easier to manage long-running jobs, notifiy users of status, etc. And then NOBODY has to sit there waiting for too long, and your HTTP connections are freed up to do something useful. Tying up the relatively expensive HTTP connection for a long-running process that requires no human interaction is kinda silly, usually. :-)
-- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So?