Lukas Kahwe Smith schreef:
On 10.07.2008, at 14:43, Richard Krehbiel wrote:
Here's the big part: I was thinking that a semantic change to persistent
sockets might make it easier for scripts to work "correctly" without
bothering them too much. The change is this: If a script doesn't
"fclose"
it's "pfsockopen"ed socket, it gets closed *for real* when the script
ends.
I suggest this because I think it would make scripts "just work" in the
presence of failures, even if the script coder doesn't completely
understand
the principle; it makes the transaction boundaries "automatic". The down
side is that, if a script forgets the fclose, things work but it doesn't
recycle sockets, it makes new ones all the time.
The other down side is that for old scripts that never had an fclose in
them, they stop getting recycled pfsockets until the fclose is added.
I'm going to do *something* about this myself, anyway. I'd really
like it
if a solution were adopted into the main code base.
I think this might generally be a solution to make persistent
connections less error prone in PHP. This includes database extensions
as well. However it does strike me as something that should be done in a
major PHP version ..
would it not be less intrusive to offer a pfclose() in a combination with
something like use_pfclose()? where by any persistent handles opened after
a call to use_pfclose() would require a pfclose() or other be truly closed
as per Richard suggestion.
In this way the "just works" principle is upheld, and there is no need
to change anything in the current behaviour. A developer can actively choose
to implement persistence state protection or whatever it might be called
outside my kingdom :-)
In addition this allows for a possible semantic change of fclose() to
allow actually closing persistent connections?
[sorry for the noise.]
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
