Re: Cleaning up streams when connection aborted

At 14:22 18/03/2002, Wez Furlong wrote:

I should have explained what I was thinking a little better: stream = php_stream_open_wrapper(...) // what if the connection aborts here? ZEND_REGISTER_RESOURCE(...)

Well, no matter how you do it, it's not going to be atomic. If you do it inside php_steam_open_wrapper() then it's just going to be 'vulnerable' for slightly less time. It's no different from: mysql_connect(&mysql, ...); // what if the connection aborts here? ZEND_REGISTER_RESOURCE(...);

Is the connection aborting asynchronous? If so, then we could lose the stream at any time prior or even during registration of the resource. So, what I was getting at is that the technique is nice, but if the allocation/registration process is not atomic, should we be doing it?

Absolutely. That's what the infrastructure is for. There's nothing inherently better you can do inside your module that will make things atomic, at best, you'll reduce the 'in danger' time. Essentially, you'd be duplicating parts of the infrastructure, which is bad... We chose to accept this limitation all over PHP.

I can see that it is better to do it this way rather than not do it at all, but that means that everywhere that streams are used (and any other resource-able allocated structure) we should be registering/unregistering resources, and that will make the code look more complicated than it really is/needs to be.

Well, you can register/unregister resources inside your stream functions. That's probably the best way to go about it.

So would it be better for the streams "subsystem" to keep track of the streams itself? Or even just register each stream as a resource during allocation of the stream?

The latter, definitely :)

Like I said, because I don't knows how the connection handling works, I was curious and wondered if there could be or should be a better way.

Connection handling varies across different web servers. If you're really paranoid, you can use HANDLE_BLOCK_INTERRUPTIONS() and HANDLE_UNBLOCK_INTERRUPTIONS() around your code, which at least under Apache, prevents certain async signals from bothering us. Connection aborting is usually detected when you fail writing information back to the browser, which means it's typically detected synchronously. Which in turn means that you should be safe :) Zeev