php code canot stop after user abort, it runs until the script is completed

Question

I am writing a website with php and there is a part of code need huge amount of time to execute.

Since I don't use thread, when I run that code, the whole server is blocked by it. But it's OK.

Hovever, even though I closed that web page, it still executes and blocked my server. I cannot access any page of my website until the process completed.

Since the execution time is very long, so that I set a very long set_time_limit() for it but I don't set ignore_user_abort so that I supposes that it should not run after user abort. Or is it the problem of curl(the code does many curl job)?

Can someone tell me that why the php script cannot stop when the user close the connection? Or there are some way to assure the script can be stopped when user abort?

Thanks.

Answer 1

From the PHP Manual:

PHP will not detect that the user has aborted the connection until an attempt is made to send information to the client.

Thus, even using ignore user abort, you must try to interact with the client again inside the script to ensure it aborts correctly. Note that on the page in question there are some additional notes about what constitutes 'sending information' (for example, an Echo doesn't qualify by itself, apparently).

Further Reading: http://php.net/manual/en/function.ignore-user-abort.php

Answer 2

Closing the browser doesn't tell the server to stop doing something. It doesn't tell the server anything.

Long-running processes don't belong in web applications. Generally you would want some background task to handle the process. Either the web application would spawn this task (this seems like a workable approach) or would in some way queue the processing of this task where a background worker would see that queue (such as a database table polled every X minutes by a daemon process).

The goal is to not block the UI while the task is running. Even if the user were to leave the browser open, the browser itself may "give up" after a while or something else could sever the user from the UX while waiting for too long. Let the user invoke the process, but separate the invocation of the process from the execution of the process so the user can return to the application interface.