[PHP-DEV] Weak references

[Chris Vandomelen]

I've written a simple extension for supporting weak (non-refcounted)
references in PHP, so that object graphs which reference themselves will
function properly. I don't know if this will be useful to anyone else, but
the code for the extension can be found at
http://4.61.245.27/~chrisv/php-ext-weakref.tgz. (Until the DSL line that
I'm in front of decides that it's going to get a new IP address, anyway..)

The extension implements 2 functions:
resource(weak reference) weakref(object $o): Returns a resource
representing the input object. The reference is not
counted against the object, and becomes invalid when the
refcount of $o becomes 0.
object weakref_get(resource(weak reference) $r): If the object
that $r represents is still valid, this increases the
refcount on the object and returns it. Otherwise it
returns false.

It should only compile against ZE2, as it needs access to
EG(objects_store) to check and see if an object reference is still valid
or not. (Unless there is some other way of checking to see if an object ID
still exists, which I didn't happen to spot during my quick browsing of
the source.)

It's one of those little things that happens to seem like a good idea
(being able to reference parent objects from a child object is a quite
handy feature at times, especially when working with stuff that looks like
DOM trees and whatnot.)

Chris



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

Re: [PHP-DEV] Weak references

[Chris Vandomelen]

Ack. Helps if I 'chmod a+r ~/public_html/php-ext-weakref.tgz'.

Chris

On Sat, 8 Mar 2003, Chris Vandomelen wrote:

> I've written a simple extension for supporting weak (non-refcounted)
> references in PHP, so that object graphs which reference themselves will
> function properly. I don't know if this will be useful to anyone else, but
> the code for the extension can be found at
> http://4.61.245.27/~chrisv/php-ext-weakref.tgz. (Until the DSL line that
> I'm in front of decides that it's going to get a new IP address, anyway..)
>
> The extension implements 2 functions:
>   resource(weak reference) weakref(object $o): Returns a resource
>   representing the input object. The reference is not
>   counted against the object, and becomes invalid when the
>   refcount of $o becomes 0.
>   object weakref_get(resource(weak reference) $r): If the object
>   that $r represents is still valid, this increases the
>   refcount on the object and returns it. Otherwise it
>   returns false.
>
> It should only compile against ZE2, as it needs access to
> EG(objects_store) to check and see if an object reference is still valid
> or not. (Unless there is some other way of checking to see if an object ID
> still exists, which I didn't happen to spot during my quick browsing of
> the source.)
>
> It's one of those little things that happens to seem like a good idea
> (being able to reference parent objects from a child object is a quite
> handy feature at times, especially when working with stuff that looks like
> DOM trees and whatnot.)
>
> Chris
>
>
>
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
>


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

Re: [PHP-DEV] Bug #11753: Need way to load sent XML

[Chris Vandomelen]

> From: [EMAIL PROTECTED]
> Operating system: Any
> PHP version:  4.0.5
> PHP Bug Type: Feature/Change Request
> Bug description:  Need way to load sent XML
>
> There appears to be no way to load an XML string that was sent to a PHP
> page with a content-type: text/xml. What I think could be appropriate is
> a function xml_load_from_request(). Then, a client could post a request
> without having to go through the trouble of form-encoding it.
>

Try using $HTTP_RAW_POST_DATA. Stuff that was POSTed with a content type
that isn't recognized by PHP will be placed there.

Chris


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #12036: Error compiling if there is blank linebefore

[Chris Vandomelen]

> 3. Lets add session feature
> ---
>
>  session_start();
> print "bla..bla..";
> ?>
> ---
> Ops.. we got an error here... !!!

That's not a bug.

session_start() wants to send a cookie to the client. But if output has
already started (the blank line before 'http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] cvs socket extension

[Chris Vandomelen]

> Morning ...
>
> Has anyone a working example on using the new socket_select()
> call with non-blocking connection-oriented sockets? blocking
> sockets with socket_accept() work like a charm. But I can't get
> socket_select() to work.

That's because of the patches that were made. Try specifying 0x7FFF or
something equally large for max_fd (the first argument to select) and it
*should* work.

The reason it doesn't work is because file descriptors were changed from
ints to resources, and since the first argument to select() (and therefore
socket_select()) must be greater than the largest file descriptor in the
set, and resource number != file descriptor.. should be obvious. :)

Try something like:

--
$someport = 3334;

$fd = socket_create_listen($someport, 5);

$fd_set = socket_fd_alloc();
socket_fd_set($fd, $fd_set);

socket_select(0x7fff, $fd_set, 0, 0, 0, 0);
--

to force the select function to see all of the file descriptors in the set
(as the socket_fd_* functions do the Right Thing when dealing with the
resources).

Chris

>
> ty
> - Markus
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] cvs socket extension

[Chris Vandomelen]

> > >
> > >socket_select(0x7fff, $fd_set, 0, 0, 0, 0);
> >
> > we can add a support function which return's the php_socket->socket integer.
>
> Glad someone came up with this.
>
> Since socket_select() always wants highest +1, couldn't this be
> implemented into socket_select() to go through all socket sets
> and get the number itself ?
>
> Or are there good reasons to let the user specify the value on
> its own ?
>

In theory, the user isn't going to be specifying sockets that aren't
accessible as resources.

The best way around this (IMHO) is to define a php_fd_set something like:

struct php_fd_set {
fd_set the_set;
intmax_fd;
};

Then, whenver someone calls fd_set() or fd_zero(), change
php_fd_set.max_fd appropriately as well as updating php_fd_set.the_set,
and in socket_select(), check all of the max_fd values.

Removing the first arg to socket_select(), if that's implemented, wouldn't
be a bad idea either.

Chris


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] cvs socket extension

[Chris Vandomelen]

> On Mon, Jul 23, 2001 at 07:20:34AM -0700, Chris Vandomelen wrote :
> > > > >
> > > > >socket_select(0x7fff, $fd_set, 0, 0, 0, 0);
> > > >
> > > > we can add a support function which return's the php_socket->socket integer.
> > >
> > > Glad someone came up with this.
> > >
> > > Since socket_select() always wants highest +1, couldn't this be
> > > implemented into socket_select() to go through all socket sets
> > > and get the number itself ?
> > >
> > > Or are there good reasons to let the user specify the value on
> > > its own ?
> > >
> >
> > In theory, the user isn't going to be specifying sockets that aren't
> > accessible as resources.
> >
> > The best way around this (IMHO) is to define a php_fd_set something like:
> >
> > struct php_fd_set {
> > fd_set the_set;
> > intmax_fd;
> > };
>
> Btw, is this really enough information ?
>
> Consider this:
> You use FD_SET() to add a socket to the set (you just bump_up
> max_fd if socket > max_Fd)
>
> But when using FD_CLR() to remove a socket how do we know
> which socket in this set has the highest number now
> and whats the number anyway (beside 42) then ?

If one is removed, it doesn't hurt the end result. If one is added outside
of max_fd and max_fd isn't raised appropriately, you run into trouble.

Chris


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] cvs socket extension

[Chris Vandomelen]

> On Mon, Jul 23, 2001 at 11:57:44PM +0200, Markus Fischer wrote:
> > On Mon, Jul 23, 2001 at 11:15:49PM +0200, Stig Venaas wrote :
> > Chris mentioned something that its not needed to restore the last
> > highest value for the max_fd if you drop the current highest one.
>
> I agree, it would only be for efficiency. I think now that the
> best solution is to just store the max. If clear.. is called
> with the current max, we can start at max and going downwards
> we can do FD_ISSET on each number until we find something that
> is set. Then we have the new max.

You can store the max, but it's not necessary to decrease it if someone
does FD_CLR() on a FD in the set. The only negative effect specifying a
larger value to select() has is extra loops in kernel space.

>
> > This makes me wondering why we not ever pass something like
> > 0x to select() [of course there is some legal reason not
> > to do this, i'm just curious now].
>
> Maybe, but I don't like it. Are you sure there are may not be bad
> things happening if the number is outside the size of the set?

See above.

BTW, you never specify 0x to select() anyway.
0x = (int) -1. :)

>
> > One the other hand, Daniel [afaik??] suggested to let the user
> > retrieve the handle id for a socket and calculate the hightest
> > value on its own. Something like
> >
> > $fd = socket_get_fd( $socket);
> >
> > comes into my mind.
> >
> >
> > The first one would be more nice for the users while the later is
> > much less programming effort :-)
>
> Yes, I think we should be nice to the users though (: There's less
> time wasted by doing it once in C than having many PHP programmers
> doing it over and over again...
>

I can't see why a user would ever need access to the actual file
descriptor returned.

> > I'm just wondering if there can be ever any drawback if we don't
> > let the user specify the first parameter to the select() call.
> >
> > As I'm not an expert I can't tell.
>
> I'm no expert, but I really can't see why it's needed (:
>

Nor do i. :)

Chris



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] cvs socket extension

[Chris Vandomelen]

On Mon, 23 Jul 2001, Jason Greene wrote:
> Just for curiosity, did you considered implementing poll instead of select? You 
>would not have to worry about specifying
> max_fd - 1.
>
> -Jason
>

I had considered poll. But it's a bit more of a hassle, and it's not
avaliable everywhere (AFAIK).

Chris


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] cvs socket extension

[Chris Vandomelen]

> On Tue, Jul 24, 2001 at 05:16:05AM +0200, Markus Fischer wrote:
> > Great :-)
> >
> > So we're seeing this getting implemented soon ?
> >
> > Volunteers, anyone ? :-))
>
> Is this select stuff so brand new that it's okay to change the API?
> If it is, we should do it quickly before too many people get to
> play with it.
>
> I think I agree now with just using the max, we can always optimize
> more later if we feel it's necessary, I think the most important
> thing now is to get rid of that argument if possible (:

The new version (renamed, cleaned up) is fairly new, so it should be fine
to do that.

Chris



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] cvs socket extension

[Chris Vandomelen]

> > The new version (renamed, cleaned up) is fairly new, so it should be fine
> > to do that.
>
> While we're at it, wouldn't it be more intuitiv to modify the
> socket_fd_*() calls to accept the fd_set resource as first
> parameter and the fd to add or remove as second parameter ?
>

No problem with that request. I'll still get them confused though. :)

> For socket_fd_set() I'ld also vote to let the second parameter be
> a single socket or an array of sockets (when you're dealing with
> many connection you're likely holding them in an array than in
> separate vars); same for socket_fd_clear(). Maybe, but I haven't
> thought more about it, it would make sense for _isset() [after
> writing this sentence I think not :) ].

*_set() and *_clear() it makes sense to accept an array for. *_isset(),
OTOH, it doesn't. "Oh, I want to know if any of the fds 5, 6, 7, or 8 are
set"... somehow that doesn't seem quite kosher. :)

Chris


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] cvs socket extension

[Chris Vandomelen]

> At 20:15 24.07.2001 +0200, Markus Fischer wrote:
> >I've come up with a patch based on the ideas and suggestion that
> >came up in this thread:
> >
> >- Let the fd_set resource keep track of the highest socket; nuked
> >   _select() first parameter and determine it ourself
> >- Swapped _set(), _clear() and _isset() parameters and
> >   recognize plain sockets as well as array of sockets
> >
> >The patch is against current CVS and only compiled unter linux
> >(debian unstable) so far.
> >
> >Please everyone interested test and verify it and let me know
> >what you think. Due my lack of karma I can't commit it anyway,
> >feel free to do so if you find it appropriate.
>
> please let me know wether the attached patch fixes your concerns.

Looks good. But it doesn't matter if someone passes no sets into select():
if there are no sets, it essentially becomes a usleep().

Chris


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] cvs socket extension

[Chris Vandomelen]

> > Looks good. But it doesn't matter if someone passes no sets into select():
> > if there are no sets, it essentially becomes a usleep().
>
> Yes I know, I had another patch which took care of this. But
> Daniels latest commit took care of everything, looks very good
> now :)

I saw the patch :)

Just didn't get far enough through my inbox to notice that it had been
committed .. especially since it was buried in about 200 other messages.
:)

Chris


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Socket Rework Complete

[Chris Vandomelen]

> For all those who don't follow CVS. The sockets extension modifications
> I listed out a few weeks ago are complete, and will be included in the
> 4.2.0 release.

I haven't been following CVS, nor have I really paid a lot of attention to
the module. I have received the occasional email about the extension
though, the most recent one being in relation to socket_select().

In the current CVS, there is a bug in the socket_select() function that
causes it to only return success or failure (RETURN_LONG(retval)), which,
if I'm not mistaken about the rest of the API changes, should be changed
to reflect a true/false value. It also doesn't give you access to the
error which occured (since retval only represents the return of socket(),
but nothing about the actual reason for failure), which is more the bug
than anything.

The way I would go about fixing it would be to change socket_select() to
return true or false, and if there was an error (as indicated by retval),
store errno somewhere and let socket_last_error()/socket_clear_error()
retrieve that value if there isn't a socket specified.

I've attached a unified diff of the changes to make. The changes are
untested (I need to actually check out a complete version before making
the changes...), but they should compile and work cleanly. (No
guarantees.)

Chris



Index: php_sockets.h
===
RCS file: /root/src/cvsroot/php4/ext/sockets/php_sockets.h,v
retrieving revision 1.22
diff -u -r1.22 php_sockets.h
--- php_sockets.h   2002/03/06 20:19:09 1.22
+++ php_sockets.h   2002/03/08 09:38:13
@@ -95,6 +95,7 @@
 
 typedef struct {
zend_bool   use_system_read;
+   int last_error;
 } php_sockets_globals;
 
 /* Prototypes */
Index: sockets.c
===
RCS file: /root/src/cvsroot/php4/ext/sockets/sockets.c,v
retrieving revision 1.95
diff -u -r1.95 sockets.c
--- sockets.c   2002/03/06 20:19:09 1.95
+++ sockets.c   2002/03/08 09:46:53
@@ -89,8 +89,13 @@
 #define PHP_NORMAL_READ 0x0001
 #define PHP_BINARY_READ 0x0002
 
-#define PHP_SOCKET_ERROR(socket,msg,errn)  socket->error = errn;   \
-  
 php_error(E_WARNING, "%s() %s [%d]: %s", get_active_function_name(TSRMLS_C), msg, 
errn, php_strerror(errn))
+#define PHP_SOCKET_ERROR(socket,msg,errn)  \
+   if (socket) \
+   socket->error = errn;   \
+   SOCKETSG(last_error) = errn;\
+   php_error(E_WARNING, "%s() %s [%d]: %s",\
+   get_active_function_name(TSRMLS_C), msg,\
+   errn, php_strerror(errn))
 
 static int le_iov;
 #define le_iov_name "Socket I/O vector"
@@ -199,6 +204,7 @@
struct sockaddr_in  la;
struct hostent  *hp;
php_socket  *sock = 
(php_socket*)emalloc(sizeof(php_socket));
+   SOCKETSLS_FETCH();
 
*php_sock = sock;
 
@@ -246,7 +252,8 @@
 {
socklen_t   salen;
php_socket  *out_sock = (php_socket*)emalloc(sizeof(php_socket));
-   
+   SOCKETSLS_FETCH();
+
*new_sock = out_sock;
salen = sizeof(*la);
 
@@ -352,6 +359,7 @@
 int php_set_inet_addr(struct sockaddr_in *sin, char *string, php_socket *php_sock  
TSRMLS_DC) {
struct in_addr tmp;
struct hostent *host_entry;
+   SOCKETSLS_FETCH();
 
if (inet_aton(string, &tmp)) {
sin->sin_addr.s_addr = tmp.s_addr;
@@ -494,6 +502,7 @@
fd_set  rfds, wfds, efds;
SOCKET  max_fd = 0;
int retval, sets = 0, usec = 0, sec=0;
+   SOCKETSLS_FETCH();
 
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "a!a!a!l|l", &r_array, 
&w_array, &e_array, &sec, &usec) == FAILURE)
return;
@@ -515,11 +524,17 @@
tv.tv_usec = usec;

retval = select(max_fd+1, &rfds, &wfds, &efds, &tv);
+
+   if (retval == -1)
+   {
+   PHP_SOCKET_ERROR(NULL, "can't select", errno);
+   RETURN_FALSE;
+   }

if (r_array != NULL) php_sock_array_from_fd_set(r_array, &rfds TSRMLS_CC);
if (w_array != NULL) php_sock_array_from_fd_set(w_array, &wfds TSRMLS_CC);
if (e_array != NULL) php_sock_array_from_fd_set(e_array, &efds TSRMLS_CC);   
-   
+
RETURN_LONG(retval); 
 
 }
@@ -629,6 +644,7 @@
zval*arg1;
php_socket  *php_sock;
int backlog = 0;
+   SOCKETSLS_FETCH();
 
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "r|l", &arg1, &backlog) 
== FAILURE)
return;
@@ -704,6 +720,7 @@
read_func   read_