Re: [PHP-DEV] Build error

[derick]

On Tue, 19 Mar 2002, Yasuo Ohgaki wrote:

> > I think this is not a good idea, the install base of re2c is very small. 
> > No major distribution includes it. 
> > 
> 
> I have no problem with that, too.
> If anyone get strange build error and you have re2c,
> suspect re2c generated files.

It won't be a problem in releases anyway, these come with the pregenerated 
files, but perhaps it's a good idea to remove the .re files from this. 
Sascha, what's your opinion on this?

Derick

---
  PHP: Scripting the Web - [EMAIL PROTECTED]
All your branches are belong to me!
SRM: Script Running Machine - www.vl-srm.net
---


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

Re: [PHP-DEV] Build error

[Yasuo Ohgaki]

[EMAIL PROTECTED] wrote:
> On Tue, 19 Mar 2002, Yasuo Ohgaki wrote:
> 
> 
>>Is it possible to bundle re2c? or make it required
>>build tool? and delete generated C source?
> 
> 
> I think this is not a good idea, the install base of re2c is very small. 
> No major distribution includes it. 
> 

I have no problem with that, too.
If anyone get strange build error and you have re2c,
suspect re2c generated files.

--
Yasuo Ohgaki



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

Re: [PHP-DEV] Build error

[derick]

On Tue, 19 Mar 2002, Yasuo Ohgaki wrote:

> Is it possible to bundle re2c? or make it required
> build tool? and delete generated C source?

I think this is not a good idea, the install base of re2c is very small. 
No major distribution includes it. 


Derick

---
  PHP: Scripting the Web - [EMAIL PROTECTED]
All your branches are belong to me!
SRM: Script Running Machine - www.vl-srm.net
---


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

Re: [PHP-DEV] Build error

[Yasuo Ohgaki]

Markus Fischer wrote:
> On Tue, Mar 19, 2002 at 04:46:10PM +0900, Yasuo Ohgaki wrote : 
> 
>>I finally found out why I get build error for CGI.
>>Since I have re2c installed on my system, it creates
>>C source. Since C source generated by re2c is in
>>repository, it can differ a little and sometimes
>>results in undefined symbol when compiling.
>>(It did in my case. Since I never edit the CVS check out,
>>I didn't expect there is a not updated C source in there)
>>
>>Is it possible to bundle re2c? or make it required
>>build tool? and delete generated C source?
>>
>>cvsclean should delete re2c generated file since
>>what it suppose to do. IMO.
> 
> 
> What undefined symbols exactly? Unless the timestamp is
> right, I always thought it's not necessary to rebuild the C
> source file.
> 

Following files were generated by re2c.

url_scanner_ex.c
var_unserializer.c

I got undefined symbol, since these files are not properly
updated. (i.e. some functions are not defined since CVS think
I deleted the lines)

If system  does not have re2c, there won't be such problem
if files are managed properly. It may not happen unless someone 
update/check out CVS source certain timing.

Although it could be rare, this could be annoying for system
that has re2c installed

And I get these diff after deleting the C file, cvs update and make.

cvs server: Diffing ext/standard
Index: ext/standard/url_scanner_ex.c
===
RCS file: /repository/php4/ext/standard/url_scanner_ex.c,v
retrieving revision 1.49
diff -u -r1.49 url_scanner_ex.c
--- ext/standard/url_scanner_ex.c   4 Mar 2002 08:37:44 -   1.49
+++ ext/standard/url_scanner_ex.c   19 Mar 2002 07:17:33 -
@@ -1,5 +1,5 @@
-/* Generated by re2c 0.5 on Fri Mar  1 17:51:19 2002 */
-#line 1 "url_scanner_ex.re"
+/* Generated by re2c 0.5 on Tue Mar 19 15:48:14 2002 */
+#line 1 "/home/yohgaki/cvs/php/HEAD/ext/standard/url_scanner_ex.re"
  /*
+--+
| PHP Version 4|
Index: ext/standard/var_unserializer.c
===
RCS file: /repository/php4/ext/standard/var_unserializer.c,v
retrieving revision 1.11
diff -u -r1.11 var_unserializer.c
--- ext/standard/var_unserializer.c 18 Mar 2002 08:22:33 -  1.11
+++ ext/standard/var_unserializer.c 19 Mar 2002 07:17:33 -
@@ -1,5 +1,5 @@
-/* Generated by re2c 0.5 on Tue Nov 27 00:35:25 2001 */
-#line 1 "/usr/src/web/php/php4/ext/standard/var_unserializer.re"
+/* Generated by re2c 0.5 on Tue Mar 19 15:44:10 2002 */
+#line 1 "/home/yohgaki/cvs/php/HEAD/ext/standard/var_unserializer.re"
  #include "php.h"
  #include "ext/standard/php_var.h"
  #include "php_incomplete_class.h"
@@ -419,7 +419,7 @@
 }
 } else
 efree(class_name);
-
+
 *p = YYCURSOR;
 elements = object_common1(UNSERIALIZE_PASSTHRU, ce);



--
Yasuo Ohgaki


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

[PHP-DEV] Re: Build error

[Yasuo Ohgaki]

Yasuo Ohgaki wrote:
> Hi,
> 
> I finally found out why I get build error for CGI.


This line is misleading. Build error may happen with
any SAPI.

--
Yasuo Ohgaki

> Since I have re2c installed on my system, it creates
> C source. Since C source generated by re2c is in
> repository, it can differ a little and sometimes
> results in undefined symbol when compiling.
> (It did in my case. Since I never edit the CVS check out,
> I didn't expect there is a not updated C source in there)
> 
> Is it possible to bundle re2c? or make it required
> build tool? and delete generated C source?
> 
> cvsclean should delete re2c generated file since
> what it suppose to do. IMO.
> 
> -- 
> Yasuo Ohgaki
> 



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

Re: [PHP-DEV] Build error

[Markus Fischer]

On Tue, Mar 19, 2002 at 04:46:10PM +0900, Yasuo Ohgaki wrote : 
> I finally found out why I get build error for CGI.
> Since I have re2c installed on my system, it creates
> C source. Since C source generated by re2c is in
> repository, it can differ a little and sometimes
> results in undefined symbol when compiling.
> (It did in my case. Since I never edit the CVS check out,
> I didn't expect there is a not updated C source in there)
> 
> Is it possible to bundle re2c? or make it required
> build tool? and delete generated C source?
> 
> cvsclean should delete re2c generated file since
> what it suppose to do. IMO.

What undefined symbols exactly? Unless the timestamp is
right, I always thought it's not necessary to rebuild the C
source file.

-- 
Please always Cc to me when replying to me on the lists.
GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc

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

[PHP-DEV] Build error

[Yasuo Ohgaki]

Hi,

I finally found out why I get build error for CGI.
Since I have re2c installed on my system, it creates
C source. Since C source generated by re2c is in
repository, it can differ a little and sometimes
results in undefined symbol when compiling.
(It did in my case. Since I never edit the CVS check out,
I didn't expect there is a not updated C source in there)

Is it possible to bundle re2c? or make it required
build tool? and delete generated C source?

cvsclean should delete re2c generated file since
what it suppose to do. IMO.

--
Yasuo Ohgaki


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

Re: [PHP-DEV] RFC: README.SUBMMITING_PATCH

[Robin Ericsson]

On Mon, 2002-03-18 at 18:53, Jim Winstead wrote:
> Zeev Suraski <[EMAIL PROTECTED]> wrote:
> > Maybe a small online interface for proposing patches (and not losing them) 
> > would bring some order to this mess, but then again, it may be an overkill.
> 
> someone was preparing a patch for the bug databases so it could handle
> file attachments. i don't know what happened with it.
> 

That would be me I guess, but I haven't got time to finish something
yet, and I'll go on vacation next week, so don't expect anything that
soon from me :(

-- 
Robin Ericsson 

"The secret of flying is to throw yourself at the ground, and miss."
-- Douglas Adams


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

Re: [PHP-DEV] poll (2) - portability/alternatives

[Jason Greene]

If a socket is added to readfds select will return if the follow occurs:

error on the socket
EOF on the socket 
data on the socket

Therefore, you should be able to call select on the socket (adding a
timeout for sanity) and if it returns call read/recv. If the return
value is 0 an EOF has occurred, if -1 an error occurred.

The worst that can happen in this scenario is that you get data, this
however can be resolved by using the MSG_PEEK option to recv, then you
don't remove the data from the buffer.

-Jason

On Mon, 2002-03-18 at 16:39, Wez Furlong wrote:
> Theres a bug in the DB where feof($sock) will not detect
> a timed-out connection.
> 
> I have a fix which uses poll(2) if available to check if
> the socket has hungup.
> 
> If poll(2) is not present, it will try to read a chunk
> of data; if that times out or sets the eof indicator,
> then an EOF is returned.
> 
> Does anyone know just how portable poll(2) is, and if
> there is an alternative portable technique to check if
> the sock is still connected?
> My man page says that libc emulates poll(2) in older
> linux kernels using select(); can anyone point me to
> some code that does this using select()?
> 
> --Wez.
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 



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

[PHP-DEV] (±¤°í)3°³¿ù ¸¸¿¡ ¿ù 500 ÀÌ»ó ¹ú ¼ö ÀÖ´Ù¸é ¹ÏÀ¸½Ã°Ú½À´Ï±î?

[°í¿µÅÃ]

Àü Á¶¼º¿î(011-441-4354)À̶ó°í ÇÕ´Ï´Ù.. ½Ç¸íÀ» ¹àÈ÷°í ¿¬¶ôó±îÁö ³²±â´Â °ÍÀº ±×¸¸Å­ »ç½ÇÀÌ°í ÇÕ¹ýÀ̱⠶§¹®ÀÔ´Ï´Ù.. 
´Ü, È£±â½ÉÀ̳ª ¹Ì¼º³âÀÚ´Â Àý´ë ¿¬¶ôÇÏÁö ¸¶¼¼¿ä.. 
Á¦°¡ ¸»¾¸ µå¸®´Â ÀÌ ÀÏÀ» ½ÃÀÛÇÑÁö´Â 1ÁÖÀÏ Á¤µµ µÇ¾ú½À´Ï´Ù.. 
´ÜÁö, ÀüÈ­»ó´ã(ÇÏ·ç¿¡ 3~4Åë)¸¸À¸·Î 3°³¿ùÀ̳»¿¡ ¿ù500¸¸¿øÀ» ¹ú ¼ö ÀÖ½À´Ï´Ù.. 
¿ì¿¬È÷ ÀÌ¿Í °°Àº ¸áÀ» ¹Þ¾Ò°í, Áö±ÝÀÇ Á¦ ½ºÆù¼­¿¡°Ô ¿¬¶ôÀ» ÇÏ°í ¸¸³µ½À´Ï´Ù.. 
¸ðµÎ°¡ µ·À» Àß¹ö´Ï Áñ°Ì°Ô ÀÏÀ» ÇÏ´õ±º¿ä.. 
Á¦ ½ºÆù¼­ÀÇ ÅëÀåÀ» È®ÀÎÇß½À´Ï´Ù.. 
½ÃÀÛÇÑÁö 2ÁÖ¹Û¿¡ ¾ÈµÇ¾ú´Âµ¥, 76¸¸¿øÀÌ ÅëÀå¿¡ µé¾î¿Í ÀÖ´õ±º¿ä.. 
±×·±µ¥, ±× ºÐÀÇ À­½ºÆù¼­ÅëÀåÀ» º¸´Ï ´õ¿í ³î¶ö ¼ö ¹Û¿¡ ¾ø¾ú½À´Ï´Ù.. 
ÇÑ´Þµ¿¾È¿¡ 1000¸¸¿øÀÌ ³Ñ´Â µ·ÀÌ ¸ÅÀÏ ³ª´µ¾î¼­ µé¾î ¿Í ÀÖ¾ú°Åµç¿ä.. 
(ÅëÀåÈ®ÀÎÇÏ°í ½ÍÀº ºÐÀº ¿¬¶ôÁֽøé ÀÎÅͳÝÁÖ¼Ò °¡¸£ÃÄ µå¸³´Ï´Ù..) 
3¿ùºÎÅÍ´Â ¿ù3000¸¸¿ø¾¿ ¹ø´Ù´Ï Àü ÀÔÀ» ´Ù¹°¼ö°¡ ¾ø¾ú½À´Ï´Ù.. 
¾Æ·¡ ³»¿ëÀº Á¦ ½ºÆù¼­°¡ Àú¿¡°Ô º¸³½ ¸áÀÔ´Ï´Ù.. 
 
 
 
¾È³çÇϼ¼¿ä? NV21ÆÀÀÇ ÀÌ OOÀÔ´Ï´Ù.. 
NV21ÆÀÀº ³×Æ®웤¸¶ÄÉÆÃÀ» ¿Â¶óÀÎÀ¸·Î À̲ø¾î °¡´Â ÆÀÀÔ´Ï´Ù.. 
ȸ¿øÀ¸·Î °¡ÀÔÇÏ½Ã¸é ¿Â¶óÀÎ È«º¸¸¦ ´ë½Å ÇØ µå¸®°í, ´Ô¿¡°Ô ¿À´Â ÀüÈ­¹®ÀǸ¸ Àß ¹ÞÀ¸½Ã¸é µË´Ï´Ù.. 
°Ü¿ì ÇÏ·ç¿¡ 3~4ÅëÀÇ ¹®ÀǸ¸ Àß ¹ÞÀ¸½Ã¸é µÇ¸ç, ù´Þ¿¡ ¸øÇصµ 100¸¸¿øÀÌ»óÀÇ ¼öÀÔÀ» ¿Ã¸®½Ç¼ö ÀÖ½À´Ï´Ù.. µÎ¹ø°´ÞºÎÅÍ´Â Àü´Þ 
¼öÀÔÀÇ µÎ¹è¾¿ »ý°¢ÇÏ½Ã¸é µË´Ï´Ù.. 
100%ÇÕ¹ýÀûÀÎ ÀÏÀ̸ç, óÀ½¿¡ 55¸¸¿ø¾îÄ¡ÀÇ ÇÚµåÆù¼±ºÒÄ«µå¸¸ ±¸ÀÔÇؼ­ ¾²½Ã¸é µË´Ï´Ù.. 
Ä«µåÇҺηΠÇÏ½Ç °æ¿ì, ÇÑ´Þ¿¡ °Ü¿ì 4¸¸¿øÁ¤µµÀÇ ÅõÀÚ°¡ µÇ´Â ¼ÀÀÔ´Ï´Ù.. 
Á¤¸» Àúµµ ÇÑÁö´Â ¾ó¸¶ ¾ÈµÇ¾úÁö¸¸, ÇÏ·ç Á¾ÀÏ Á¦°¡ ÇÏ°í ½ÍÀº ÀÏÇÏ°í ÇÏ·ç¿¡ °Ü¿ì ÀüÈ­ 3~4Åë ¹ÞÀ¸¸é¼­ ù´ÞºÎÅÍ 160¸¸¿øÀÇ 
¼öÀÔÀ» ¾ò¾ú½À´Ï´Ù..´ÙÀ½´ÞÀº ¾à 300¸¸¿øÀÌ»óÀÌ µÉ °Í °°³×¿ä.. 
---½Ã½ºÅÛÀ» ¿ä¾àÇؼ­ ¼³¸í µå¸®¸é- 
1. ȸ¿ø°¡ÀÔÇϽøé, ¿Â¶óÀÎÈ«º¸¸¦ 2ÁÖÀϵ¿¾È ´ÔÀÇ À̸§À¸·Î ÇØ µå¸³´Ï´Ù.. 
2. È«º¸°¡ ½ÃÀ۵Ǹé, ÇÏ·ç¿¡ 3~4ÅëÀÇ ¿¬¶ôÀÌ ¿Ã °ÍÀÔ´Ï´Ù.. 
3. ±×·³, °£´ÜÈ÷ µ·¹ö´Â ½Ã½ºÅÛ¿¡ ´ëÇØ ¼³¸íÇØ ÁÖ°í ¹ÌÆþà¼Ó Àå¼Ò¿Í ½Ã°£À» Á¤ÇÕ´Ï´Ù.. 
4. ±×´ÙÀ½ NV21ÆÀ¿¡°Ô ¿¬¶ôÁֽøé NV21ÆÀ¿øµéÀÌ ´ë½Å ¹ÌÆÃÀ» ÇÏ°í ´Ô ¹ØÀ¸·Î °¡ÀÔÀ» ½ÃÄѵå 
¸³´Ï´Ù.. 
5. ¼öÀÔÀº ¼ö´çÁ¶°Ç¼º¸³ÀϷκÎÅÍ 5ÀÏµÚ ¸ÅÀÏ Áö±ÞÇÕ´Ï´Ù.. 
 
È£±â½ÉÀ̳ª 20¼¼ ¹Ì¸¸Àº Àý´ë ÀüÈ­ÇÏÁö ¸¶½Ã°í¿ä.. 
Á¤¸»·Î µ·¹ú°í ½ÍÀº ºÐ¸¸ ¿¬¶ôÁÖ¼¼¿ä.. 
 
 
À­ ±ÛÀ» Àаí 
óÀ½¿£ ¹ÏÁö ¾Ê¾ÒÁö¸¸, Àú ¿ª½Ã ±×´ë·Î µû¶óÇÏ°í ÀÖ°í, ´ÙÀ½ÁÖ¸é ½ÃÀÛÇÑÁö 2ÁÖ¸¸¿¡ ¾à 60¸¸¿ø 
ÀÌ µé¾î¿É´Ï´Ù.. ¼ö´çÀº ½ÇÀûÀÌ ÀϾ ³¯·ÎºÎÅÍ 5ÀÏµÚ ¸ÅÀÏ Áö±ÞÇÕ´Ï´Ù.. 
Á¤¸»·Î ÀÌ ÀÏ¿¡ ´ëÇØ Á¦´ë·Î ¾Ë¾Æº¸°í µ·À» ¹ú°í ½ÍÀº ºÐÀº ¿¬¶ôÁÖ¼¼¿ä.. 
Áö±Ý±îÁö º» ¸¶ÄÉÆÿ¡¼­ °¡Àå ¼ºÀåÇϱâ ÁÁÀº ½Ã½ºÅÛÀ̶ó°í »ý°¢ÇÕ´Ï´Ù 
Âü°í·Î ÀúÀÇȸ»ç »çÀå´ÔÀº °¡¼ö À±¼öÀÏ ¾¾ÀÔ´Ï´Ù 
12ÁÖ¼º°øÇÁ·Î±×·¥À» ÅëÇØ 3°³¿ù ¸¸¿¡ ÀÏ¹Ý Á÷ÀåÀÎ ¿ù±ÞÀÇ 
3~5¹è¸¦ ¹ú ¼ö ÀÖ´Ù¸é ¹ÏÀ¸½Ã°Ú½À´Ï±î? 
°ÅÁþ¸»À̶ó°í »ý°¢ÇϽô ºÐÀÌ ÀÖ°ÚÁö¸¸, ±ØÈ÷ »ç½ÇÀÔ´Ï´Ù.. 
ÇöÀç NV21À» ÅëÇØ »ç¾÷ÇϽô ȸ¿øÁß 80%ÀÌ»óÀÌ 12ÁÖ¼º°øÇÁ·Î±×·¥ÀÇ ¸ñÇ¥ÀÌ»óÀ» ´Þ¼ºÇÏ°í ÀÖ½À´Ï´Ù. 
¼±ºÒÄ«µå³×Æ®웤ȸ»çÀÎ NTIÀÇ ¿Â¶óÀλç¾÷ÆÀÀÎ NV21Àº ÀÏ¹Ý »ó½ÄÀ¸·Î´Â ¹Ï±â ¾î·Á¿î 
±âÀûÀ» ÀÌ·ç¾î ³»°í ÀÖ½À´Ï´Ù.. 
ÀÚ¼¼ÇÑ ¾ÆÀÌÅÛÀ̳ª °¡ÀÔ¹æ¹ý¿¡ ´ëÇØ ¾Ë°í ½ÍÀº ºÐÀº ȨÆäÀÌÁö¹Ù·Î°¡±â¸¦ Ŭ¸¯ÇØ ÁÖ 
¼¼¿ä. 
¶ÇÇÑ, »ó´ãÀ» ¿øÇÏ´Â ºÐÀº Àú¿¡°Ô ¹Ù·Î ¿¬¶ôÁֽðųª ȨÆäÀÌÁöÀÇ »ó´ã¿¹¾à Äڳʸ¦ 
ÀÌ¿ëÇØ ÁÖ¼¼¿ä.. 
ÃßõÀÎ Á¶¼º¿î(011-441-4354) 
 
´õÁÁÀº Á¤º¸¸¦ ¾Ë°í ½ÍÀ¸½Ã¸é 011-441-4354 Á¶¼º¿î ÀúÇÑÅ× ¿¬¶ôÁֽðí¿ä 
http://nti21.biz ȨÆäÀÌÁö¸¦ ¹æ¹®Çغ¸¼¼¿ä 
±×¸®°í ÀüÇô°ü½ÉÀÌ ¾ø´Â ºÐ¿¡°Ô À̱ÛÀÌ Àü´ÞµÇ¾úÀ¸¸é Á˼ÛÇÕ´Ï´Ù 
±×·±µ¥ µ·À»¹ú°í »ýÈ°ÀÌ À±ÅÃÇØÁú¼öÀÖ´Â Á¤º¸¶ó ´©±¸³ª µµ¿òÀÌ µÇ¸®¶ó »ý°¢ÇÕ´Ï´Ù 



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

[PHP-DEV] iconv configure problem

[Jon Parise]

The latest iconv detection code doesn't appear to account for the
case where iconv_open() is defined in libiconv.  It only checks
for iconv_open() in libc and libiconv_open() in libiconv.

This breaks the build under FreeBSD unless the GNU libiconv port
is installed.

-- 
Jon Parise ([EMAIL PROTECTED])  .  Information Technology (2001)
http://www.csh.rit.edu/~jon/  :  Computer Science House Member

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

[PHP-DEV] XtOffsetOf Nightmare

[Alex Black]

hi all,

I have entered bugs.
I have mailed the install list.
No response.

I was unable to compile PHP 4.1.2 with Apache 1.3.23. I have previously
compiled extremely complex installs without a hitch.

After a huge amount of digging, It seems that XtOffsetOf is the source of
all of my problems.

During an initial compile of PHP 4.1.2 --with-apache I get the following
errors:

/root/bc_install/packages/apache_1.3.23/src/include/ap_config_auto.h:6:
 unterminated `#if' conditional
/root/bc_install/packages/apache_1.3.23/src/include/ap_config.h:1386
`XtOffsetOf' redefined

So. First problem, I had to patch ap_config_auto.h to fix the broken
conditional.

Second problem. I found an XtOffsetOf define in main/php.h

commented that out.

I couldn't get it all to compile with mm... which seemed just to be a stupid
path problem (though it has worked before) but I now have a functional
install.

has anyone tested with PHP 4.1.2 Apache 1.3.23?

it was a nightmare... :)

_alex


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

Re: [PHP-DEV] Re: [PEAR-DEV] Improving speed -> caching hash results in zend_execute?

[Sterling Hughes]

> Does anyone want to comment on this (the full threads on PEAR-DEV), 
> about the results (2) and (3),  - 2 is a wrapper call to another 
> function 3 is directly calling a function/method - I think it was 20,000 
> times (1) is the original PEARdb call - with some extra ifs...etc.
> 
> anyway - the overhead for wrapping the call was quite high..
> 
> I had a look at the code in zend_execute.c (in ZE2 & ZE1) - the question 
> goes something like this - I'm guessing that it's the hash table lookups 
> being repeatedly called causing this slowdown. (couldnt see anything 
> else...)
> 
> Would it not be an idea to cache in the opcode for the function call the 
> result of the last hashtable lookup, then check if that lookup was valid 
> first rather than doing a hashtable lookup on each call?
> 
> (or am I talking out my ass :)
> 

you're talking out your ass :)

-Sterling
* The breakfast of champions is not cereal, it's the opposition. *

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

[PHP-DEV] Re: [PEAR-DEV] Improving speed -> caching hash results in zend_execute?

[Alan Knowles]

Does anyone want to comment on this (the full threads on PEAR-DEV), 
about the results (2) and (3),  - 2 is a wrapper call to another 
function 3 is directly calling a function/method - I think it was 20,000 
times (1) is the original PEARdb call - with some extra ifs...etc.

anyway - the overhead for wrapping the call was quite high..

I had a look at the code in zend_execute.c (in ZE2 & ZE1) - the question 
goes something like this - I'm guessing that it's the hash table lookups 
being repeatedly called causing this slowdown. (couldnt see anything 
else...)

Would it not be an idea to cache in the opcode for the function call the 
result of the last hashtable lookup, then check if that lookup was valid 
first rather than doing a hashtable lookup on each call?

(or am I talking out my ass :)

regards
alan


Tomas V.V.Cox wrote:

>Alan Knowles wrote:
>
>> Thomas - does it make any difference if you add a fast fetch method?
>>Class DB
>>
>>funcition fastFetchInto(&$arr|,$fetchmode|) {|
>>return  $this->dbh->fetchInto($this->result, $arr, $fetchmode);|
>>}
>>
>
>It makes some difference yeah, but still not all we would want to get:
>Results:
>1 -> 26.209026 seconds
>2 -> 13.831852 seconds
>3 -> 19.579646 seconds
>
>> 
>>
>
>
>
>Tomas V.V.Cox
>




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

[PHP-DEV] Re: SMP machines and shared memory

[Yasuo Ohgaki]

This is known issue and it does not matter if system is SMP or not.
Multiple users have been reporting this problem on occasion.

--
Yasuo Ohgaki


Warwick Poole wrote:
> I dont know if this is the correct forum to ask this question, but I
> have spent a good day trying to find the answer to this with no real
> success, so I thought I would try the source...the PHP developers.
> 
> I am building a cluster of 3 webservers, which are going to serve a
> group of PHP (with some Perl scripts as well) websites. Its a high load
> environment so I have gone with SMP machines (dual Processor i686, 1GB
> RAM, running a tuned RedHat 7.2 with kernel 2.4.18 with tweaks). 
> 
> I am trying to tweak the OS, Apache and PHP as far as I possibly can. I
> want to use Shared Memory for the session handlers in PHP, so I have
> compiled with --with-mm and set "session.save_handler=mm" in php.ini.
> 
> I have been told that PHP has "serious concurrency bugs" when using SMP
> machines and shared memory. I cant find this documented anywhere.
> However I am told that the current-stable 4.1.2 still has issues with
> SMP and SHM whereas the CVS version (which built as 4.2.1-dev on my
> machine) has resolved this issue.
> 
> What is the current status regarding this? Any information that you can
> share would be greatly appreciated.
> 
> Thanks
> Warwick Poole 



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

[PHP-DEV] Re: Global data with session handler

[Yasuo Ohgaki]

Brad Lafountain wrote:
> I was wondering if anyone has ever thought of comming up with a different way
> of handling the code below. I know that you can use shared memory, but that
> wont work for win and it wont work for web cluseters using db's to handle their
> sessions. Also sessions will automatically handle locking of the session info.
> so you don't need to worry about using shm locking the shm.

Basically you need application level sesssion variable (or application 
scope persistent variable), right?

SRM and session_pgsql supports that.
In case of session_pgsql, $_APP can be used just like $_SESSION.
All session that has the same session name shares $_APP.
(SRM has OO approch for this)

Supporting $_APP is easy, if nobody objects I'll add it to files
handler or change session module so that all save handler
can support $_APP easily.

Any comments?

--
Yasuo Ohgaki



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

[PHP-DEV] fgetss_state - seemingly unused

[Wez Furlong]

Hey,

Does anyone know what purpose FG(fgetss_state) serves?
It doesn't appear to do anything other than hold the value
0 for php_strip_tags.

Is this an oversight or a leftover of some old code?

The zlib extension has it's own equivalent that also
does nothing.

Are they safe to nuke?

--Wez.


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

[PHP-DEV] Re: Bug #16135: Release breaks due to C++ requirement

[Marko Karppinen]

>> I haven't heard from [EMAIL PROTECTED] yet why he introduced
>> this at all (he is now explicitly Cc'ed).  Note that it has
>> not been removed from the 4.2.0 branch yet.
> 
> I removed it from the branch now. Do you want me to close this report?

Unfortunately the details escape me; this was to fix a libmysql compile bust
on OS X. I wanted to have a CXX check, but *requiring* it was accidental.
The issue seems to be gone now, so I'm not going to miss the checks.

Sorry about the mixup, luckily it seems we only got a single end-user bug
report about this. (#15261, which I'm now closing.)

--Marko

-- 
Marko Karppinen - http://homepage.mac.com/marko/


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

[PHP-DEV] poll (2) - portability/alternatives

[Wez Furlong]

Theres a bug in the DB where feof($sock) will not detect
a timed-out connection.

I have a fix which uses poll(2) if available to check if
the socket has hungup.

If poll(2) is not present, it will try to read a chunk
of data; if that times out or sets the eof indicator,
then an EOF is returned.

Does anyone know just how portable poll(2) is, and if
there is an alternative portable technique to check if
the sock is still connected?
My man page says that libc emulates poll(2) in older
linux kernels using select(); can anyone point me to
some code that does this using select()?

--Wez.


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

Re: [PHP-DEV] Global data with session handler

[Richard Heyes]

brad lafountain <[EMAIL PROTECTED]> wrote:

>  I couldn't find such a file. (4.1.2)

http://cvs.php.net/cvs.php/pear/Cache/Application.php
-- 
Richard Heyes


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

RE: [PHP-DEV] FTP returns wrong file size (and a fix) - second try

[Joseph Tate]

I can condone that course of action.  Go ahead and commit it.  I'd make a
not of it in the documentation so that somebody doesn't get seriously bitten
by it.

> -Original Message-
> From: Vlad Krupin [mailto:[EMAIL PROTECTED]]
> Sent: Monday, March 18, 2002 5:08 PM
> To: [EMAIL PROTECTED]
> Cc: Joseph Tate; PHP Developers Mailing List
> Subject: Re: [PHP-DEV] FTP returns wrong file size (and a fix) - second
> try
>
>
> If someone needs an ASCII size, they need to scream and file a bug
> report and then I'll implement it. This function has not been working
> properly for ages and no-one complained. This way at least it will work
> consistently and make sense. Optional ASCII mode size will require a
> bloat (like an optional parameter) :(.
>
> Vlad
>
>
>
> [EMAIL PROTECTED] wrote:
>
> >On Mon, 18 Mar 2002, Joseph Tate wrote:
> >
> >>Would there ever be a need to get the ASCII ftp_size?  If not,
> the go ahead,
> >>but if there ever might be, you may want to add a parameter to
> ftp_size so
> >>that it behaves like ftp_get et all.  The parameter could
> default to BINARY.
> >>
> >
> >That sounds like a good idea to me. I can't think of a way why
> it would be
> >useful, but it doesn't hurt either. I'd go for the ftp_size()
> with default
> >BINARY, and optional ASCII mode size. (And it's fine with me to merge it)
> >
> >regards,
> >Derick
> >
> >>Joseph
> >>
> >>>-Original Message-
> >>>From: Vlad Krupin [mailto:[EMAIL PROTECTED]]
> >>>Sent: Monday, March 18, 2002 4:15 PM
> >>>To: PHP Developers Mailing List
> >>>Cc: [EMAIL PROTECTED]
> >>>Subject: [PHP-DEV] FTP returns wrong file size (and a fix) - second try
> >>>
> >>>
> >>>Hi, this is the second try to get feedback and  to make a fix to
> >>>ftp_size() function.
> >>>After bringing that issue up a few days back, I got response
> from Derick
> >>>only with some concerns, which I'll address here.
> >>>Please, respond or I'll just apply the patch because it makes sense to
> >>>me and see what happens.
> >>>
> >>>
> >>>First of all, ftp_size() function is broken. It will return different
> >>>results for the same file depending on what function was called before
> >>>it. To fix it, we have to set the mode of the ftp server session to
> >>>BINARY rather than ASCII. It is a one-liner patch.
> >>>
> >>>Derick was concerned that this will change the state of the session
> >>>without the user explicitly requesting it and we do not restore it.
> >>>However, this is irrelevant since all the functions that depend on that
> >>>state will set it for themselves:
> >>>- ftp_nlist() and ftp_rawlist() already do just that - they
> just set the
> >>>type to ASCII and do not restore it.
> >>>- ftp_get(), ftp_fget(), ftp_put() and ftp_fput() require you
> to set the
> >>>type explicitly
> >>>- other functions do not depend on transfer type (except for
> ftp_size() ).
> >>>
> >>>It was an obvious oversight not to make ftp_size() set the mode before
> >>>requesting the size of a file (I would have never imagined
> that the size
> >>>of the file differs depending on whether we do 'dir' in text mode or
> >>>binary mode... duh!)
> >>>
> >>>So, to wrap it up. Making that change will not affect *any* other
> >>>functionality of the ftp extension (you are welcome to read through the
> >>>source - I just did that) and will fix ftp_size() to
> consistently return
> >>>correct results.
> >>>
> >>>Question: Does anybody object to putting that change in, *and* also
> >>>merging it into the release branch? This is an obvious bug, and the fix
> >>>doesn't affect anything else.
> >>>
> >>>Vlad
> >>>
> >>>
> >>>
> >>>
> >>>--
> >>>PHP Development Mailing List 
> >>>To unsubscribe, visit: http://www.php.net/unsub.php
> >>>
> >
> >---
> >  PHP: Scripting the Web - [EMAIL PROTECTED]
> >All your branches are belong to me!
> >SRM: Script Running Machine - www.vl-srm.net
> >---
> >
>
>
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php


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

Re: [PHP-DEV] FTP returns wrong file size (and a fix) - second try

[Vlad Krupin]

If someone needs an ASCII size, they need to scream and file a bug 
report and then I'll implement it. This function has not been working 
properly for ages and no-one complained. This way at least it will work 
consistently and make sense. Optional ASCII mode size will require a 
bloat (like an optional parameter) :(.

Vlad



[EMAIL PROTECTED] wrote:

>On Mon, 18 Mar 2002, Joseph Tate wrote:
>
>>Would there ever be a need to get the ASCII ftp_size?  If not, the go ahead,
>>but if there ever might be, you may want to add a parameter to ftp_size so
>>that it behaves like ftp_get et all.  The parameter could default to BINARY.
>>
>
>That sounds like a good idea to me. I can't think of a way why it would be 
>useful, but it doesn't hurt either. I'd go for the ftp_size() with default 
>BINARY, and optional ASCII mode size. (And it's fine with me to merge it)
>
>regards,
>Derick
>
>>Joseph
>>
>>>-Original Message-
>>>From: Vlad Krupin [mailto:[EMAIL PROTECTED]]
>>>Sent: Monday, March 18, 2002 4:15 PM
>>>To: PHP Developers Mailing List
>>>Cc: [EMAIL PROTECTED]
>>>Subject: [PHP-DEV] FTP returns wrong file size (and a fix) - second try
>>>
>>>
>>>Hi, this is the second try to get feedback and  to make a fix to
>>>ftp_size() function.
>>>After bringing that issue up a few days back, I got response from Derick
>>>only with some concerns, which I'll address here.
>>>Please, respond or I'll just apply the patch because it makes sense to
>>>me and see what happens.
>>>
>>>
>>>First of all, ftp_size() function is broken. It will return different
>>>results for the same file depending on what function was called before
>>>it. To fix it, we have to set the mode of the ftp server session to
>>>BINARY rather than ASCII. It is a one-liner patch.
>>>
>>>Derick was concerned that this will change the state of the session
>>>without the user explicitly requesting it and we do not restore it.
>>>However, this is irrelevant since all the functions that depend on that
>>>state will set it for themselves:
>>>- ftp_nlist() and ftp_rawlist() already do just that - they just set the
>>>type to ASCII and do not restore it.
>>>- ftp_get(), ftp_fget(), ftp_put() and ftp_fput() require you to set the
>>>type explicitly
>>>- other functions do not depend on transfer type (except for ftp_size() ).
>>>
>>>It was an obvious oversight not to make ftp_size() set the mode before
>>>requesting the size of a file (I would have never imagined that the size
>>>of the file differs depending on whether we do 'dir' in text mode or
>>>binary mode... duh!)
>>>
>>>So, to wrap it up. Making that change will not affect *any* other
>>>functionality of the ftp extension (you are welcome to read through the
>>>source - I just did that) and will fix ftp_size() to consistently return
>>>correct results.
>>>
>>>Question: Does anybody object to putting that change in, *and* also
>>>merging it into the release branch? This is an obvious bug, and the fix
>>>doesn't affect anything else.
>>>
>>>Vlad
>>>
>>>
>>>
>>>
>>>--
>>>PHP Development Mailing List 
>>>To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>
>---
>  PHP: Scripting the Web - [EMAIL PROTECTED]
>All your branches are belong to me!
>SRM: Script Running Machine - www.vl-srm.net
>---
>




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

RE: [PHP-DEV] FTP returns wrong file size (and a fix) - second try

[derick]

On Mon, 18 Mar 2002, Joseph Tate wrote:

> Would there ever be a need to get the ASCII ftp_size?  If not, the go ahead,
> but if there ever might be, you may want to add a parameter to ftp_size so
> that it behaves like ftp_get et all.  The parameter could default to BINARY.

That sounds like a good idea to me. I can't think of a way why it would be 
useful, but it doesn't hurt either. I'd go for the ftp_size() with default 
BINARY, and optional ASCII mode size. (And it's fine with me to merge it)

regards,
Derick

> 
> Joseph
> 
> > -Original Message-
> > From: Vlad Krupin [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, March 18, 2002 4:15 PM
> > To: PHP Developers Mailing List
> > Cc: [EMAIL PROTECTED]
> > Subject: [PHP-DEV] FTP returns wrong file size (and a fix) - second try
> >
> >
> > Hi, this is the second try to get feedback and  to make a fix to
> > ftp_size() function.
> > After bringing that issue up a few days back, I got response from Derick
> > only with some concerns, which I'll address here.
> > Please, respond or I'll just apply the patch because it makes sense to
> > me and see what happens.
> >
> >
> > First of all, ftp_size() function is broken. It will return different
> > results for the same file depending on what function was called before
> > it. To fix it, we have to set the mode of the ftp server session to
> > BINARY rather than ASCII. It is a one-liner patch.
> >
> > Derick was concerned that this will change the state of the session
> > without the user explicitly requesting it and we do not restore it.
> > However, this is irrelevant since all the functions that depend on that
> > state will set it for themselves:
> > - ftp_nlist() and ftp_rawlist() already do just that - they just set the
> > type to ASCII and do not restore it.
> > - ftp_get(), ftp_fget(), ftp_put() and ftp_fput() require you to set the
> > type explicitly
> > - other functions do not depend on transfer type (except for ftp_size() ).
> >
> > It was an obvious oversight not to make ftp_size() set the mode before
> > requesting the size of a file (I would have never imagined that the size
> > of the file differs depending on whether we do 'dir' in text mode or
> > binary mode... duh!)
> >
> > So, to wrap it up. Making that change will not affect *any* other
> > functionality of the ftp extension (you are welcome to read through the
> > source - I just did that) and will fix ftp_size() to consistently return
> > correct results.
> >
> > Question: Does anybody object to putting that change in, *and* also
> > merging it into the release branch? This is an obvious bug, and the fix
> > doesn't affect anything else.
> >
> > Vlad
> >
> >
> >
> >
> > --
> > PHP Development Mailing List 
> > To unsubscribe, visit: http://www.php.net/unsub.php
> 

---
  PHP: Scripting the Web - [EMAIL PROTECTED]
All your branches are belong to me!
SRM: Script Running Machine - www.vl-srm.net
---


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

Re: [PHP-DEV] Global data with session handler

[brad lafountain]

--- Richard Heyes <[EMAIL PROTECTED]> wrote:
> brad lafountain <[EMAIL PROTECTED]> wrote:
> 
> > I was wondering if anyone has ever thought of comming up with a different
> way
> > of handling the code below. I know that you can use shared memory, but
> that
> > wont work for win and it wont work for web cluseters using db's to handle
> > their
> > sessions. Also sessions will automatically handle locking of the session
> info.
> > so you don't need to worry about using shm locking the shm.
> 
> There's a class in PEAR to do application sessions, Cache/Application.php.

 I couldn't find such a file. (4.1.2)
> 
> -- 
> Richard Heyes
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


__
Do You Yahoo!?
Yahoo! Sports - live college hoops coverage
http://sports.yahoo.com/

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

RE: [PHP-DEV] FTP returns wrong file size (and a fix) - second try

[Joseph Tate]

Would there ever be a need to get the ASCII ftp_size?  If not, the go ahead,
but if there ever might be, you may want to add a parameter to ftp_size so
that it behaves like ftp_get et all.  The parameter could default to BINARY.

Joseph

> -Original Message-
> From: Vlad Krupin [mailto:[EMAIL PROTECTED]]
> Sent: Monday, March 18, 2002 4:15 PM
> To: PHP Developers Mailing List
> Cc: [EMAIL PROTECTED]
> Subject: [PHP-DEV] FTP returns wrong file size (and a fix) - second try
>
>
> Hi, this is the second try to get feedback and  to make a fix to
> ftp_size() function.
> After bringing that issue up a few days back, I got response from Derick
> only with some concerns, which I'll address here.
> Please, respond or I'll just apply the patch because it makes sense to
> me and see what happens.
>
>
> First of all, ftp_size() function is broken. It will return different
> results for the same file depending on what function was called before
> it. To fix it, we have to set the mode of the ftp server session to
> BINARY rather than ASCII. It is a one-liner patch.
>
> Derick was concerned that this will change the state of the session
> without the user explicitly requesting it and we do not restore it.
> However, this is irrelevant since all the functions that depend on that
> state will set it for themselves:
> - ftp_nlist() and ftp_rawlist() already do just that - they just set the
> type to ASCII and do not restore it.
> - ftp_get(), ftp_fget(), ftp_put() and ftp_fput() require you to set the
> type explicitly
> - other functions do not depend on transfer type (except for ftp_size() ).
>
> It was an obvious oversight not to make ftp_size() set the mode before
> requesting the size of a file (I would have never imagined that the size
> of the file differs depending on whether we do 'dir' in text mode or
> binary mode... duh!)
>
> So, to wrap it up. Making that change will not affect *any* other
> functionality of the ftp extension (you are welcome to read through the
> source - I just did that) and will fix ftp_size() to consistently return
> correct results.
>
> Question: Does anybody object to putting that change in, *and* also
> merging it into the release branch? This is an obvious bug, and the fix
> doesn't affect anything else.
>
> Vlad
>
>
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php


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

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/exif exif.c

[Marcus Börger]

At 21:52 18.03.2002, you wrote:
> > 2) for seekable streams the copy function should seek to 0 if
> > copying all, shouldn't it?
>
>No: as an example consider some code that is performing an HTTP request.
>It might want to store the headers in one stream and the body in another.
>So, it would manually loop and store the headers line by line until
>it hits the blank line separator and then use copy_to_stream to
>stick the rest of the data in the other stream.

Well that seems a good reason!

>
> > 3) the patch below shows that as expected only one line has to be
> > modified in order to use temp-streams instead of temp-files directly.
> > But you would have to reenable memory_streams.c. I tried it and it
> > worked fine for me.
>
>I want to do some tests before doing this; but there should be no
>problems.

I tested it myself with ext/exif and an image with about 70mb because
ext/exif does many seeks and mostly small read operations in it. Also
it worked with all other test images.
Tell me when done, so i can add documentation.

marcus


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

[PHP-DEV] FTP returns wrong file size (and a fix) - second try

[Vlad Krupin]

Hi, this is the second try to get feedback and  to make a fix to 
ftp_size() function.
After bringing that issue up a few days back, I got response from Derick 
only with some concerns, which I'll address here.
Please, respond or I'll just apply the patch because it makes sense to 
me and see what happens.


First of all, ftp_size() function is broken. It will return different 
results for the same file depending on what function was called before 
it. To fix it, we have to set the mode of the ftp server session to 
BINARY rather than ASCII. It is a one-liner patch.

Derick was concerned that this will change the state of the session 
without the user explicitly requesting it and we do not restore it. 
However, this is irrelevant since all the functions that depend on that 
state will set it for themselves:
- ftp_nlist() and ftp_rawlist() already do just that - they just set the 
type to ASCII and do not restore it.
- ftp_get(), ftp_fget(), ftp_put() and ftp_fput() require you to set the 
type explicitly
- other functions do not depend on transfer type (except for ftp_size() ).

It was an obvious oversight not to make ftp_size() set the mode before 
requesting the size of a file (I would have never imagined that the size 
of the file differs depending on whether we do 'dir' in text mode or 
binary mode... duh!)

So, to wrap it up. Making that change will not affect *any* other 
functionality of the ftp extension (you are welcome to read through the 
source - I just did that) and will fix ftp_size() to consistently return 
correct results.

Question: Does anybody object to putting that change in, *and* also 
merging it into the release branch? This is an obvious bug, and the fix 
doesn't affect anything else.

Vlad




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

Re: [PHP-DEV] Global data with session handler

[Richard Heyes]

brad lafountain <[EMAIL PROTECTED]> wrote:

> I was wondering if anyone has ever thought of comming up with a different
way
> of handling the code below. I know that you can use shared memory, but
that
> wont work for win and it wont work for web cluseters using db's to handle
> their
> sessions. Also sessions will automatically handle locking of the session
info.
> so you don't need to worry about using shm locking the shm.

There's a class in PEAR to do application sessions, Cache/Application.php.

-- 
Richard Heyes


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

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/exif exif.c

[Wez Furlong]

On 18/03/02, "Marcus Börger"  wrote:
> If have the following annotations to streams:
> 1) i do not like the style of how to determine the kine of a stream
> instead of
> #define php_stream_is(stream, anops)((stream)->ops == anops)
> #define PHP_STREAM_IS_STDIO &php_stream_stdio_ops
> 
> i would like a 'call form' like
> #define php_stream_is(stream, anops)((stream)->ops == anops)
> #define PHP_STREAM_IS_STDIO(stream) \
>  php_stream_is (stream,&php_stream_stdio_ops)

I do prefer the former (which is why I wrote it that way). I don't
think it makes much difference, because not much code should be calling
it anyway.

> 2) for seekable streams the copy function should seek to 0 if
> copying all, shouldn't it?

No: as an example consider some code that is performing an HTTP request.
It might want to store the headers in one stream and the body in another.
So, it would manually loop and store the headers line by line until
it hits the blank line separator and then use copy_to_stream to
stick the rest of the data in the other stream. 
 
> 3) the patch below shows that as expected only one line has to be
> modified in order to use temp-streams instead of temp-files directly.
> But you would have to reenable memory_streams.c. I tried it and it
> worked fine for me.

I want to do some tests before doing this; but there should be no
problems.

--Wez.


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

[PHP-DEV] Global data with session handler

[brad lafountain]

I was wondering if anyone has ever thought of comming up with a different way
of handling the code below. I know that you can use shared memory, but that
wont work for win and it wont work for web cluseters using db's to handle their
sessions. Also sessions will automatically handle locking of the session info.
so you don't need to worry about using shm locking the shm.



i guess what im suggesting is something like this



( i know about the session_register is depericated... its just register_globals
is on on my machine so i'm using it :) )

Any comments?

:Brad


__
Do You Yahoo!?
Yahoo! Sports - live college hoops coverage
http://sports.yahoo.com/

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

Re: [PHP-DEV] Re: user-space streams ?

[Wez Furlong]

On 19/03/02, "l0t3k" <[EMAIL PROTECTED]> wrote:
> Wez,
> +2e32-1
> you read my mind ! but does this also entails having an OO interface to
> the streams as they are. it would be very annoying to have a cool stream
> abstraction interface, but then have to check for every resource list entry
> under the sun to access the stream_ops (le_ftp, le_file, le_xxx, etc).

Streams _are_ implemented in an OO way, so none of this applies.

--Wez.



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

[PHP-DEV] SMP machines and shared memory

[Warwick Poole]

I dont know if this is the correct forum to ask this question, but I
have spent a good day trying to find the answer to this with no real
success, so I thought I would try the source...the PHP developers.

I am building a cluster of 3 webservers, which are going to serve a
group of PHP (with some Perl scripts as well) websites. Its a high load
environment so I have gone with SMP machines (dual Processor i686, 1GB
RAM, running a tuned RedHat 7.2 with kernel 2.4.18 with tweaks). 

I am trying to tweak the OS, Apache and PHP as far as I possibly can. I
want to use Shared Memory for the session handlers in PHP, so I have
compiled with --with-mm and set "session.save_handler=mm" in php.ini.

I have been told that PHP has "serious concurrency bugs" when using SMP
machines and shared memory. I cant find this documented anywhere.
However I am told that the current-stable 4.1.2 still has issues with
SMP and SHM whereas the CVS version (which built as 4.2.1-dev on my
machine) has resolved this issue.

What is the current status regarding this? Any information that you can
share would be greatly appreciated.

Thanks
Warwick Poole 

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

[PHP-DEV] Re: user-space streams ?

[l0t3k]

Wez,
+2e32-1
you read my mind ! but does this also entails having an OO interface to
the streams as they are. it would be very annoying to have a cool stream
abstraction interface, but then have to check for every resource list entry
under the sun to access the stream_ops (le_ftp, le_file, le_xxx, etc).


"Wez Furlong" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> I thought it might be nice to allow people writing class
> libraries in PHP/PEAR to be able to roll-their-own streams using
> PHP code.
>
> It would be implemented something like the user-mode session module
> handler, but a bit more OO; they would declare a class (see below)
> and register it as a wrapper using a new user-space function called
> file_register_wrapper(string $protocol, string $classname).
>
> file_register_wrapper would fail if the wrapper is already registered.
>
> The php_stream_open_wrapper function would create an instance of the
> class and then call it's methods when the equivalent methods in
> the php_stream_ops structure are called.
>
> This would allow some really cool things, like defining a custom
> protocol and then passing that custom URL around to all sorts of
> PHP functions (fopen(), copy(), extension functions that use wrappers)
> and have them handle it without even noticing that it's implemented
> in PHP code.
>
> Comments please!
>
> --Wez.
>
>
> class my_stream {
>function open($path, $mode, $options, &$opened_path)
>{
>   return true/false;
>}
>function read($count)
>{
>   return false on error;
>   else return string;
>}
>function write($data)
>{
>   return false on error;
>   else return count written;
>}
>function close()
>{
>}
>function flush()
>{
>}
> /* these are optional */
>function seek($offset, $whence)
>{
>}
>function gets($size)
>{
>   return false on error;
>   else return string;
>}
> }
>
>



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

RE: [PHP-DEV] RFC: Small changes in CODING_STANDARD

[Zeev Suraski]

At 19:35 18/03/2002, Chris Newbill wrote:
>Except is should be side-effect, not side of effect. :)
  Oh yeah:)


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

[PHP-DEV] CVS Account Request: lsmith

[Lukas Smith]

PEAR related work =>
Working on the Metabase - PEAR DB Merge

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

Re: [PHP-DEV] RFC: README.SUBMITTING_PATCH (2nd edition)

[derick]

On Mon, 18 Mar 2002, Markus Fischer wrote:

> On Mon, Mar 18, 2002 at 12:03:50PM -0500, James E. Flemer wrote : 
> > What about in-line vs. attachments? For patching,
> > attachments are probably easier, but for reviewing I find
> > it useful if the patch is in-line.
> > 
> 
> -1 ...
> 
> If the patch is not inline you will have hard time extracting
> it.

A patch in an attachemtn is more convenient, just save and patch, while 
inline patches need copying/pasting and or cutting.

Derick

---
  PHP: Scripting the Web - [EMAIL PROTECTED]
All your branches are belong to me!
SRM: Script Running Machine - www.vl-srm.net
---


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

Re: [PHP-DEV] RFC: README.SUBMMITING_PATCH

[Jim Winstead]

Zeev Suraski <[EMAIL PROTECTED]> wrote:
> Maybe a small online interface for proposing patches (and not losing them) 
> would bring some order to this mess, but then again, it may be an overkill.

someone was preparing a patch for the bug databases so it could handle
file attachments. i don't know what happened with it.

jim

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

Re: [PHP-DEV] RFC: README.SUBMITTING_PATCH (2nd edition)

[Markus Fischer]

On Mon, Mar 18, 2002 at 12:03:50PM -0500, James E. Flemer wrote : 
> What about in-line vs. attachments? For patching,
> attachments are probably easier, but for reviewing I find
> it useful if the patch is in-line.
> 

-1 ...

If the patch is not inline you will have hard time extracting
it.

If your MUA doesn't display patches properly you should fix
this first ...

- Markus

-- 
Please always Cc to me when replying to me on the lists.
GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc

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

RE: [PHP-DEV] RFC: Small changes in CODING_STANDARD

[Chris Newbill]

Except is should be side-effect, not side of effect. :)

-Chris

-Original Message-
From: Yasuo Ohgaki [mailto:[EMAIL PROTECTED]] 
Sent: Monday, March 18, 2002 1:23 AM
To: Zeev Suraski
Cc: [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] RFC: Small changes in CODING_STANDARD

Zeev Suraski wrote:
> At 09:50 18/03/2002, Yasuo Ohgaki wrote:
> 
>> Markus Fischer wrote:
>>
>>> I wouldn't uset the word Heisenbugs. Not every developer is
>>> familiar with it. Do you think it's possible to use a more
>>> descriptive sentence?
>>
>>
>>
>> Oh. I agree.
>> How about
>>
>>  - Do not use assignment in assert condition. If assignment is used,
>>there is risk that we have disapearing bug with debug build due to
>>side of effect of assignment. Function calls in assert condition
>>may create this bug also when parameter or global variable is
>>changed.
> 
> 
> Do not use assignments in assert conditions.  If you assign inside an 
> assert condition, you risk an elusive bug that would be very difficult

> to spot in a debug build, due to the side of effect of the assignment.

> Function calls in assert conditions may also cause this problem, if
they 
> modify one of their arguments or global variables.
> 
> 

Thanks a lot.
Much easier to understand for me too :)

--
Yasuo Ohgaki


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


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

Re: [PHP-DEV] Cleaning up streams when connection aborted

[Zeev Suraski]

At 18:51 18/03/2002, Wez Furlong wrote:
> > Connection handling varies across different web servers.  If you're really
> > paranoid, you can use
> >
> > HANDLE_BLOCK_INTERRUPTIONS()
> > and
> > HANDLE_UNBLOCK_INTERRUPTIONS()
>
>Should I bother with this in streams?

Well, I wouldn't :)

Zeev


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

Re: [PHP-DEV] RFC: README.SUBMITTING_PATCH (2nd edition)

[James E. Flemer]

What about in-line vs. attachments? For patching,
attachments are probably easier, but for reviewing I find
it useful if the patch is in-line.

-James

On Mon, 18 Mar 2002, Yasuo Ohgaki wrote:

> Hi all,
>
> I've added David and Zeev's suggestion and added a little.
> Please fix/add/comment. Thank you.
>
> 
> Submitting Patch for PHP
> 
>
> This document describes how to submit patch for PHP. Since you are
> reading this document, you are willing to submit patch for PHP!
> Please keep reading! Submitting patch for PHP is easy.
>
> How to create patch?
> 
> We are working with CVS. You need to get CVS source to create patch
> that we accept.  Visit http://www.php.net/anoncvs.php to get CVS
> source. You can check out older versions, but make sure you get
> default branch (i.e. Do not use -r option when you check out CVS
> source)
>
> Now you are ready to create patch. Modify source to fix bugs in PHP or
> add new feature to PHP. After you finished editing, please test your
> patch. Read README.TESTING for testing.
>
> After you finish testing your patch, take diff file using
> "cvs diff > your.patch" command.
>
> Read README.TESTING for submitting test script for your patch. This is
> not strictly required, but it is preferred to submit test script along
> with your patch. Making new test script is very easy. It help us to
> understand what you have been fixed or added to PHP.
>
>
> Tips for creating patch
> ---
> If you would like to fix multiple bugs. It is easier for us if you
> could create 1 patch for 1 bugs, but it's not strictly required.
>
> If you would like change/add many lines, you may better to ask module
> maintainer and/or [EMAIL PROTECTED]  Official module maintainers
> can be found in EXTENSIONS file in PHP source.
>
>
> Recommended CVS client settings for getting patch file
> --
> Recommended ~/.cvsrc file setting is:
> --
> cvs -z3
> update -d -P
> checkout -P
> diff -u -b -w -B
> --
> diff -u -b -w -B means:
>   -b Ignore changes in amount of white space.
>   -B Ignore changes that just insert or delete blank lines.
>   -u Use the unified output format.
>   -w Ignore white space when comparing lines.
>
> With this CVS setting, you don't have to worry about adding/deleting
> newlines and new spaces.
>
>
> Check list for submitting patch
> ---
>   - Did you run "make test" to check if your patch didn't break
> other features?
>   - Did you compile PHP with --enable-debug and check php/webserver
> error logs when you test your patch?
>   - Did you build PHP for multi-threaded web servers. (Optional)
>   - Did you create test script for "make test"? (Optional)
>   - Did you check your patch is unified format and it does not
> contain white space changes? (If you are not using recommended
> cvs setting)
>   - Did you update CVS source before you take final patch?
>
>
> Where to send your patch?
> -
> You are supposed to send patch to [EMAIL PROTECTED] If you
> are patching module, you should also send patch to the maintainer.
> Official module maintainers are listed in EXTENSION file in source.
>
> Make sure you add "[PATCH]" prefix to mail subject. Please make sure
> attach patch file even if patch is really short one. Finally, explain
> what has been fixed/added/changed by your patch.
>
> If you know bug ID that can be closed by your patch, please note the
> bug ID numbers also.
>
>
>
> How long it will take to get response?
> --
> Since we are volunteers, it may take more than a few days to get
> response. If you didn't get any response in a few days, please let us
> know you have been submitted the patch, but you didn't get any
> response.
>
>
> Thank you for sending patch for PHP!
>
>
>


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

Re: [PHP-DEV] Cleaning up streams when connection aborted

[Wez Furlong]

On 18/03/02, "Zeev Suraski" <[EMAIL PROTECTED]> wrote:
> 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 :)

Good; that's what I thought :-)
 
> Connection handling varies across different web servers.  If you're really 
> paranoid, you can use
> 
> HANDLE_BLOCK_INTERRUPTIONS()
> and
> HANDLE_UNBLOCK_INTERRUPTIONS()

Should I bother with this in streams?
 
> 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 :)

That helps me get the picture.

Thanks Zeev,

--Wez.



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

[PHP-DEV] Re: Bug #16135: Release breaks due to C++ requirement

[Derick Rethans]

On Mon, 18 Mar 2002, Sascha Schumann wrote:

> On Mon, 18 Mar 2002, Derick Rethans wrote:
> 
> > Hello Sascha,
> >
> > I thought you removed this requirement last week from CVS:
> > http://news.php.net/article.php?group=php.cvs&article=9895
> 
> I haven't heard from [EMAIL PROTECTED] yet why he introduced
> this at all (he is now explicitly Cc'ed).  Note that it has
> not been removed from the 4.2.0 branch yet.

I removed it from the branch now. Do you want me to close this report?

Derick

> 
> revision 1.295
> date: 2002/01/26 23:57:17;  author: markonen;  state: Exp;  lines: +199 -99
> - Reorganized stuff in configure.in and added a few comments
> # This isn't nearly as big a change as the diff would lead one to believe.
> # I've tested this on all my machines and its working for sniper too.
> - Added a check for ApplicationServices/ApplicationServices.h (Mac OS X)
> - Added AC_PROG_CPP, AC_PROG_CXX and AC_PROG_CXXCPP
> # (the bundled libmysql build was failing without them with ac2.52/OSX)
> - Improved the IPv6 check to fail on Mac OS X (there's no IPv6 there yet)
> 
> 
> 
> > > From: [EMAIL PROTECTED]
> > > Operating system: All
> > > PHP version:  4.0CVS-2002-03-18
> > > PHP Bug Type: Compile Failure
> > > Bug description:  Release breaks due to C++ requirement
> > >
> > > Regardless of PHP being written in C, there has been a new unused
> > > requirement been introduced which causes configure to fail always, if the
> > > system does not have a C++ compiler installed. This is quite common,
> > > especially on web-servers where in the ideal case no compiler would be
> > > installed at all. This will potentially generate dozens of reports and
> > > clog mailing lists, because owners of up-to-date and esoteric systems
> > > alike will be affected by this issue.
> > > --
> > > Edit bug report at http://bugs.php.net/?id=16135&edit=1
> 
> - Sascha Experience IRCG
>   http://schumann.cx/http://schumann.cx/ircg
> 


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

Re: [PHP-DEV] Cleaning up streams when connection aborted

[Zeev Suraski]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] RFC: README.SUBMITTING_PATCH (2nd edition)

[James Cox]

can we replace "submit patch" with "submit a patch" etc.

it's better english.

james

> -Original Message-
> From: Yasuo Ohgaki [mailto:[EMAIL PROTECTED]]
> Sent: Monday, March 18, 2002 10:18 AM
> To: [EMAIL PROTECTED]
> Subject: [PHP-DEV] RFC: README.SUBMITTING_PATCH (2nd edition)
> 
> 
> Hi all,
> 
> I've added David and Zeev's suggestion and added a little.
> Please fix/add/comment. Thank you.
> 
> 
> Submitting Patch for PHP
> 
> 
> This document describes how to submit patch for PHP. Since you are
> reading this document, you are willing to submit patch for PHP!
> Please keep reading! Submitting patch for PHP is easy.
> 
> How to create patch?
> 
> We are working with CVS. You need to get CVS source to create patch
> that we accept.  Visit http://www.php.net/anoncvs.php to get CVS
> source. You can check out older versions, but make sure you get
> default branch (i.e. Do not use -r option when you check out CVS
> source)
> 
> Now you are ready to create patch. Modify source to fix bugs in PHP or
> add new feature to PHP. After you finished editing, please test your
> patch. Read README.TESTING for testing.
> 
> After you finish testing your patch, take diff file using
> "cvs diff > your.patch" command.
> 
> Read README.TESTING for submitting test script for your patch. This is
> not strictly required, but it is preferred to submit test script along
> with your patch. Making new test script is very easy. It help us to
> understand what you have been fixed or added to PHP.
> 
> 
> Tips for creating patch
> ---
> If you would like to fix multiple bugs. It is easier for us if you
> could create 1 patch for 1 bugs, but it's not strictly required.
> 
> If you would like change/add many lines, you may better to ask module
> maintainer and/or [EMAIL PROTECTED]  Official module maintainers
> can be found in EXTENSIONS file in PHP source.
> 
> 
> Recommended CVS client settings for getting patch file
> --
> Recommended ~/.cvsrc file setting is:
> --
> cvs -z3
> update -d -P
> checkout -P
> diff -u -b -w -B
> --
> diff -u -b -w -B means:
>   -b Ignore changes in amount of white space.
>   -B Ignore changes that just insert or delete blank lines.
>   -u Use the unified output format.
>   -w Ignore white space when comparing lines.
> 
> With this CVS setting, you don't have to worry about adding/deleting
> newlines and new spaces.
> 
> 
> Check list for submitting patch
> ---
>   - Did you run "make test" to check if your patch didn't break
> other features?
>   - Did you compile PHP with --enable-debug and check php/webserver
> error logs when you test your patch?
>   - Did you build PHP for multi-threaded web servers. (Optional)
>   - Did you create test script for "make test"? (Optional)
>   - Did you check your patch is unified format and it does not
> contain white space changes? (If you are not using recommended
> cvs setting)
>   - Did you update CVS source before you take final patch?
> 
> 
> Where to send your patch?
> -
> You are supposed to send patch to [EMAIL PROTECTED] If you
> are patching module, you should also send patch to the maintainer.
> Official module maintainers are listed in EXTENSION file in source.
> 
> Make sure you add "[PATCH]" prefix to mail subject. Please make sure
> attach patch file even if patch is really short one. Finally, explain
> what has been fixed/added/changed by your patch.
> 
> If you know bug ID that can be closed by your patch, please note the
> bug ID numbers also.
> 
> 
> 
> How long it will take to get response?
> --
> Since we are volunteers, it may take more than a few days to get
> response. If you didn't get any response in a few days, please let us
> know you have been submitted the patch, but you didn't get any
> response.
> 
> 
> Thank you for sending patch for PHP!
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

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

Re: [PHP-DEV] Cleaning up streams when connection aborted

[Wez Furlong]

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(...)

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?

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.

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?

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.

--Wez.


On 18/03/02, "Zeev Suraski" <[EMAIL PROTECTED]> wrote:
> At 13:04 18/03/2002, Wez Furlong wrote:
> >I've noticed a couple of places in the code where ZEND_REGISTER_RESOURCE
> >is used to remember to cleanup streams, and then deletes the list entry
> >when it has completed what it was doing.
> >
> >It's a nice idea, but it doesn't feel safe to me (probably because
> >I'm not 100% aware of the way that PHP handles the connection aborting),
> 
> I'm not sure why you think it's unsafe..?  That's one of the key advantages 
> of using the resource infrastructure.  I can't see how streams are 
> different from any other resource.
> 
> Zeev




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

Re: [PHP-DEV] Cleaning up streams when connection aborted

[Zeev Suraski]

At 13:04 18/03/2002, Wez Furlong wrote:
>I've noticed a couple of places in the code where ZEND_REGISTER_RESOURCE
>is used to remember to cleanup streams, and then deletes the list entry
>when it has completed what it was doing.
>
>It's a nice idea, but it doesn't feel safe to me (probably because
>I'm not 100% aware of the way that PHP handles the connection aborting),

I'm not sure why you think it's unsafe..?  That's one of the key advantages 
of using the resource infrastructure.  I can't see how streams are 
different from any other resource.

Zeev


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

[PHP-DEV] Cleaning up streams when connection aborted

[Wez Furlong]

I've noticed a couple of places in the code where ZEND_REGISTER_RESOURCE
is used to remember to cleanup streams, and then deletes the list entry
when it has completed what it was doing.

It's a nice idea, but it doesn't feel safe to me (probably because
I'm not 100% aware of the way that PHP handles the connection aborting),
since we can't guarantee that the stream allocation and resource
registration is atomic (can we?).

Should we consider removing the resource registration and instead have
the streams code keep a list of all the persistent/non-persistent streams
it has allocated, so that it can cleanup on request shutdown?

When dealing with persistent streams I'd need to cleanup in the module
shutdown, right?

Also, I'd appreciate it if someone that knows about the persistent
resource mechanism could bring me up to speed on what I should/should not
being doing with persistent streams (currently only pfsockopened streams
are persistent).

Thanks!

--Wez.


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

[PHP-DEV] MySQL 4.0.1 support gone?

[Michael Kunze]

Hi all,

I'm still having trouble to compile latest CVS on Linux with MySQL 4.0.1
(see bug 16139). Has support for MySQL 4.0.1 been withdrawn from CVS?

Cheers

Michael


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

[PHP-DEV] Re: STREAMS_DC/CC macros

[Wez Furlong]

On 18/03/02, "Zeev Suraski" <[EMAIL PROTECTED]> wrote:
> Ok, so basically you're saying that you're doing much more relaying than 
> the standard one-level relaying?

Yes :-)

>  Ok, that makes sense (are you sure you'd 
> want the get the outermost level, though?  from my experience you'd usually 
> want just the closest layer, but things may be different with the streams).

I suppose it's down to personal preference; my goal was to find out where
the stream was opened, and since allocations in streams typically only occur
when opening, it should be quite simple to follow the execution path to
find the closest layer, if needed.
This has the nice advantage of telling the programmer when they have
forgotten to close the streams, or assign them to resources.
(that part is worth discussing; I'll send another email about that).
 
> At any rate, if you do want this multilevel relaying, I think you can 
> achieve it with only changing the _REL macro, and without having to change 
> the others:
> 
> 1.  Put __php_stream_call_depth inside the stream globals (I think you 
> don't have a stream globals structure, so you can put them in the PHP core 
> globals).
> 2.  Increment/decrement it inside each of the functions you are tracking
> 3.  Use TSRM macros for everything, except for the _REL macros

OK; I'll try and do this sometime today.

Is it possible to define the TSRMLS_D macro to something that the compiler
can catch in a debug build under non-TSRM conditions?

--Wez.


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

[PHP-DEV] Re: STREAMS_DC/CC macros

[Zeev Suraski]

Ok, so basically you're saying that you're doing much more relaying than 
the standard one-level relaying?  Ok, that makes sense (are you sure you'd 
want the get the outermost level, though?  from my experience you'd usually 
want just the closest layer, but things may be different with the streams).

At any rate, if you do want this multilevel relaying, I think you can 
achieve it with only changing the _REL macro, and without having to change 
the others:

1.  Put __php_stream_call_depth inside the stream globals (I think you 
don't have a stream globals structure, so you can put them in the PHP core 
globals).
2.  Increment/decrement it inside each of the functions you are tracking
3.  Use TSRM macros for everything, except for the _REL macros

Zeev

At 12:25 18/03/2002, Wez Furlong wrote:
>Hi Zeev,
>
>If you look in main/php_streams.h, you'll see where I am coming from.
>Those rel_orig macros (as they stand now!) look like "thinkos" on my
>part.
>
>The concept is that the original php_stream_xxx call that triggered
>the allocation is relayed to the memory manager, as well as listing
>the place where the actual allocation took place.  Since there can
>be a number of levels of nested calls during stream_open_wrapper,
>I needed these macros rather than "plain" emalloc_rel because it
>didn't propogate the original file/line variables.
>
>If you can see a nicer way of achieving this, I'm all ears!
>
>--Wez.
>
>On 18/03/02, "Zeev Suraski" <[EMAIL PROTECTED]> wrote:
> > Are they really necessary?  A lot of work has been done to make everything
> > in PHP use the same thing, so I'd really like the avoid introducing new
> > macros at this point...
> >
> > I can tell that the basic difference is the use of 
> __php_stream_call_depth,
> > but I really can't see how you're using it :)
> >
> > #define emalloc_rel_orig(size)\
> >   ( __php_stream_call_depth == 0 \
> >   ? _emalloc((size) ZEND_FILE_LINE_CC 
> ZEND_FILE_LINE_ORIG_RELAY_CC) \
> >   : _emalloc((size) ZEND_FILE_LINE_CC 
> ZEND_FILE_LINE_ORIG_RELAY_CC) )
> >
> > #define erealloc_rel_orig(ptr, size)  \
> >   ( __php_stream_call_depth == 0 \
> >   ? _erealloc((ptr), (size), 0 ZEND_FILE_LINE_CC
> > ZEND_FILE_LINE_ORIG_RELAY_CC) \
> >   : _erealloc((ptr), (size), 0 ZEND_FILE_LINE_CC
> > ZEND_FILE_LINE_ORIG_RELAY_CC) )
> >
> >
> > Am I missing something, or are the lines of code 100% identical whether
> > __php_stream_call_depth is 0 or not?  I can see that you are using it in
> > the REL macros, but if that's the only place you're using them, it's
> > probably better to use a special macro for that, and not replace the TSRM
> > macro completely (you can probably put __php_stream_call_depth inside your
> > stream globals, to avoid having move an extra variable around all the
> > time).  Also, I don't exactly understand the whole concept of this
> > __php_stream_call_depth and why you'd like to use __zend_orig_filename
> > instead of __zend_filename based on its value.  Can you shed some light on
> > this?
> >
> > Zeev


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

[PHP-DEV] Re: STREAMS_DC/CC macros

[Wez Furlong]

Hi Zeev,

If you look in main/php_streams.h, you'll see where I am coming from.
Those rel_orig macros (as they stand now!) look like "thinkos" on my
part.

The concept is that the original php_stream_xxx call that triggered
the allocation is relayed to the memory manager, as well as listing
the place where the actual allocation took place.  Since there can
be a number of levels of nested calls during stream_open_wrapper,
I needed these macros rather than "plain" emalloc_rel because it
didn't propogate the original file/line variables.

If you can see a nicer way of achieving this, I'm all ears!

--Wez.

On 18/03/02, "Zeev Suraski" <[EMAIL PROTECTED]> wrote:
> Are they really necessary?  A lot of work has been done to make everything 
> in PHP use the same thing, so I'd really like the avoid introducing new 
> macros at this point...
> 
> I can tell that the basic difference is the use of __php_stream_call_depth, 
> but I really can't see how you're using it :)
> 
> #define emalloc_rel_orig(size)\
>   ( __php_stream_call_depth == 0 \
>   ? _emalloc((size) ZEND_FILE_LINE_CC ZEND_FILE_LINE_ORIG_RELAY_CC) \
>   : _emalloc((size) ZEND_FILE_LINE_CC ZEND_FILE_LINE_ORIG_RELAY_CC) )
> 
> #define erealloc_rel_orig(ptr, size)  \
>   ( __php_stream_call_depth == 0 \
>   ? _erealloc((ptr), (size), 0 ZEND_FILE_LINE_CC 
> ZEND_FILE_LINE_ORIG_RELAY_CC) \
>   : _erealloc((ptr), (size), 0 ZEND_FILE_LINE_CC 
> ZEND_FILE_LINE_ORIG_RELAY_CC) )
> 
> 
> Am I missing something, or are the lines of code 100% identical whether 
> __php_stream_call_depth is 0 or not?  I can see that you are using it in 
> the REL macros, but if that's the only place you're using them, it's 
> probably better to use a special macro for that, and not replace the TSRM 
> macro completely (you can probably put __php_stream_call_depth inside your 
> stream globals, to avoid having move an extra variable around all the 
> time).  Also, I don't exactly understand the whole concept of this 
> __php_stream_call_depth and why you'd like to use __zend_orig_filename 
> instead of __zend_filename based on its value.  Can you shed some light on 
> this?
> 
> Zeev




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

Re: [PHP-DEV] Re: Leaking streams..

[Wez Furlong]

Hi Zeev,

You are correct, but I didn't see any leaks anyway, and could not
see how or where the leaks might be; so if anything, it didn't make
sense that Jani saw the leaks :-)

No one else has reported leaks (yet) either.

--Wez.

On 18/03/02, "Zeev Suraski" <[EMAIL PROTECTED]> wrote:
> Just wondering - Wez, does it make sense to you that the leaks are 
> gone?  Didn't you only change the memory allocations to use the relay 
> tracking feature of the memory manager, which should not actually effect 
> the number of leaks? :)
> 
> Zeev
> 
> At 02:28 18/03/2002, Wez Furlong wrote:
> >On 18/03/02, "Jani Taskinen" <[EMAIL PROTECTED]> wrote:
> > > Well..with latest CVS I don't get any leak log entries.
> >
> >Great!
> >
> >--Wez.
> >
> >
> >
> >--
> >PHP Development Mailing List 
> >To unsubscribe, visit: http://www.php.net/unsub.php




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

[PHP-DEV] RFC: README.SUBMITTING_PATCH (2nd edition)

[Yasuo Ohgaki]

Hi all,

I've added David and Zeev's suggestion and added a little.
Please fix/add/comment. Thank you.


Submitting Patch for PHP


This document describes how to submit patch for PHP. Since you are
reading this document, you are willing to submit patch for PHP!
Please keep reading! Submitting patch for PHP is easy.

How to create patch?

We are working with CVS. You need to get CVS source to create patch
that we accept.  Visit http://www.php.net/anoncvs.php to get CVS
source. You can check out older versions, but make sure you get
default branch (i.e. Do not use -r option when you check out CVS
source)

Now you are ready to create patch. Modify source to fix bugs in PHP or
add new feature to PHP. After you finished editing, please test your
patch. Read README.TESTING for testing.

After you finish testing your patch, take diff file using
"cvs diff > your.patch" command.

Read README.TESTING for submitting test script for your patch. This is
not strictly required, but it is preferred to submit test script along
with your patch. Making new test script is very easy. It help us to
understand what you have been fixed or added to PHP.


Tips for creating patch
---
If you would like to fix multiple bugs. It is easier for us if you
could create 1 patch for 1 bugs, but it's not strictly required.

If you would like change/add many lines, you may better to ask module
maintainer and/or [EMAIL PROTECTED]  Official module maintainers
can be found in EXTENSIONS file in PHP source.


Recommended CVS client settings for getting patch file
--
Recommended ~/.cvsrc file setting is:
--
cvs -z3
update -d -P
checkout -P
diff -u -b -w -B
--
diff -u -b -w -B means:
  -b Ignore changes in amount of white space.
  -B Ignore changes that just insert or delete blank lines.
  -u Use the unified output format.
  -w Ignore white space when comparing lines.

With this CVS setting, you don't have to worry about adding/deleting
newlines and new spaces.


Check list for submitting patch
---
  - Did you run "make test" to check if your patch didn't break
other features?
  - Did you compile PHP with --enable-debug and check php/webserver
error logs when you test your patch?
  - Did you build PHP for multi-threaded web servers. (Optional)
  - Did you create test script for "make test"? (Optional)
  - Did you check your patch is unified format and it does not
contain white space changes? (If you are not using recommended
cvs setting)
  - Did you update CVS source before you take final patch?


Where to send your patch?
-
You are supposed to send patch to [EMAIL PROTECTED] If you
are patching module, you should also send patch to the maintainer.
Official module maintainers are listed in EXTENSION file in source.

Make sure you add "[PATCH]" prefix to mail subject. Please make sure
attach patch file even if patch is really short one. Finally, explain
what has been fixed/added/changed by your patch.

If you know bug ID that can be closed by your patch, please note the
bug ID numbers also.



How long it will take to get response?
--
Since we are volunteers, it may take more than a few days to get
response. If you didn't get any response in a few days, please let us
know you have been submitted the patch, but you didn't get any
response.


Thank you for sending patch for PHP!


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

Re: [PHP-DEV] RFC: README.SUBMMITING_PATCH

[Zeev Suraski]

At 10:19 18/03/2002, David Eriksson wrote:
>Maybe add something about unified format for the diff?

Definitely.

>"I personally refuse to use inferior tools because of ideology."
> - Linus Torvalds

Good quote :)

Zeev


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

Re: [PHP-DEV] file.c broken

[Sebastian Bergmann]

Sebastian Bergmann wrote:
> [snip]

  Didn't notice those before:

c:\home\php\php4\main\main.c(569): error C2065:
'tsrm_ls': Undeclared identifier

c:\home\php\php4\main\main.c(569): warning C4022:
_php_stream_open_wrapper': 
Pointer type for passed parameter 5 does not matched declared pointer
type

c:\home\php\php4\main\streams.c(646): warning C4047: 'function':
Number of dereferences of 'char **' and 'void ***' different

c:\home\php\php4\main\streams.c(646): warning C4024: '_php_stream_fopen':
Types for formal and passed parameter 3 do not match

c:\home\php\php4\main\streams.c(886): error C2065: 'tsrm_ls':
Undeclared identifier

c:\home\php\php4\main\streams.c(956) : error C2082:
Formal parameter "tsrm_ls" redefined

-- 
  Sebastian Bergmann
  http://sebastian-bergmann.de/ http://phpOpenTracker.de/

  Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

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

Re: [PHP-DEV] RFC: README.SUBMMITING_PATCH

[David Eriksson]

On Mon, 18 Mar 2002, Yasuo Ohgaki wrote:

> Hi all,
> 
> We get questions like "where to send path?" on occasion.
> We should have doc for that. Here is a draft.
> Please fix/add/comment. Thank you.

Maybe add something about unified format for the diff?

Personally I would recommend this line in the ~/.cvsrc file:

diff -u -b -w -B

 -b Ignore changes in amount of white space.
 -B Ignore changes that just insert or delete blank lines.
 -u Use the unified output format.
 -w Ignore white space when comparing lines.


-\- David Eriksson -/-

"I personally refuse to use inferior tools because of ideology."
- Linus Torvalds 




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

[PHP-DEV] STREAMS_DC/CC macros

[Zeev Suraski]

Are they really necessary?  A lot of work has been done to make everything 
in PHP use the same thing, so I'd really like the avoid introducing new 
macros at this point...

I can tell that the basic difference is the use of __php_stream_call_depth, 
but I really can't see how you're using it :)

#define emalloc_rel_orig(size)  \
( __php_stream_call_depth == 0 \
? _emalloc((size) ZEND_FILE_LINE_CC ZEND_FILE_LINE_ORIG_RELAY_CC) \
: _emalloc((size) ZEND_FILE_LINE_CC ZEND_FILE_LINE_ORIG_RELAY_CC) )

#define erealloc_rel_orig(ptr, size)\
( __php_stream_call_depth == 0 \
? _erealloc((ptr), (size), 0 ZEND_FILE_LINE_CC 
ZEND_FILE_LINE_ORIG_RELAY_CC) \
: _erealloc((ptr), (size), 0 ZEND_FILE_LINE_CC 
ZEND_FILE_LINE_ORIG_RELAY_CC) )


Am I missing something, or are the lines of code 100% identical whether 
__php_stream_call_depth is 0 or not?  I can see that you are using it in 
the REL macros, but if that's the only place you're using them, it's 
probably better to use a special macro for that, and not replace the TSRM 
macro completely (you can probably put __php_stream_call_depth inside your 
stream globals, to avoid having move an extra variable around all the 
time).  Also, I don't exactly understand the whole concept of this 
__php_stream_call_depth and why you'd like to use __zend_orig_filename 
instead of __zend_filename based on its value.  Can you shed some light on 
this?

Zeev 


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