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


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to