Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Stig Sæther Bakken]

[Walter Franzini <[EMAIL PROTECTED]>]
> [sorry, my English is bad]
> 
> Zeev Suraski <[EMAIL PROTECTED]> writes:
> 
> [...]
> 
> > Why?  Whatever extension you use on your box, put them in the php.ini.
> > dl() is never a better option.
> >
> > Zeev
> 
> An example not solvable using php.ini:
> 
> At SysNet, we access dbms only with odbc_* functions using (for
> different apps on the same server) solid and IBMdb2.
> 
> We compile ext/odbc/php_odbc.c as solid.so and ibmdb2.so and load the
> right module using dl ().  Using php.ini is not feasible because this
> lead to multiple function definition.
> 
> I think a similar situation may arise with multiple xslt backend, they
> must export the same API but could provide different features (or
> bugs) so you must use xslt1 for app1 and xslt2 for app2.
> 
> Please don't drop dl () :-)

Shane Caraveo did some work on the ODBC module to solve this once, by
using macros for all potentially clashing symbols in the ext/odbc
source.  It's not there anymore though, and that's mostly my fault.  I
guess we could go back to that model.

 - Stig

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
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] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Zeev Suraski]

At 11:37 28-08-01, Walter Franzini wrote:

>[sorry, my English is bad]
>
>Zeev Suraski <[EMAIL PROTECTED]> writes:
>
>[...]
>
> > Why?  Whatever extension you use on your box, put them in the php.ini.
> > dl() is never a better option.
> >
> > Zeev
>
>An example not solvable using php.ini:
>
>At SysNet, we access dbms only with odbc_* functions using (for
>different apps on the same server) solid and IBMdb2.
>
>We compile ext/odbc/php_odbc.c as solid.so and ibmdb2.so and load the
>right module using dl ().  Using php.ini is not feasible because this
>lead to multiple function definition.
>
>I think a similar situation may arise with multiple xslt backend, they
>must export the same API but could provide different features (or
>bugs) so you must use xslt1 for app1 and xslt2 for app2.
>
>Please don't drop dl () :-)

We're not dropping it :)  It works just as well as it did until now, which 
is not too well.  Solving the problems that arise by deprecating dl() 
(improving the ODBC module, for instance) are much easier than solving the 
problems that fixing the broken things about dl().  Right now, we're simply 
keeping the status-quo.

Zeev


-- 
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] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Andi Gutmans]

At 09:39 AM 8/8/2001 +0200, Thies C. Arntzen wrote:
>On Wed, Aug 08, 2001 at 09:28:02AM +0200, Stig Sæther Bakken
>wrote:
> > [Zeev Suraski <[EMAIL PROTECTED]>]
> > > At 17:55 07-08-01, Stig Sæther Bakken wrote:
> > > >Now we're talking!  I assume it is not straightforward, what are the
> > > >technical challenges in doing JIT module initialization?
> > >
> > > It's not much of a challenge really.  If we decide it should be done,
> > > it can be done...
> >
> > Ok, so it's just a matter of "minit_done" and "rinit_done" properties
> > for each module?  Let's go for that, and either keep dl() or replace
> > it with php_load_extension() (the difference being that the latter
> > knows what file extension to use on your platform).
>
> sascha had a patch for this some time ago - the "gain" was
> near to zero. this might make sense once we "hit" the few
> hundred extension border...

Yeah I also remember it didn't give us anything. I think the most notably 
impact with shared libraries is the load time of the shared library itself. 
It is not significant in the web environment though when PHP is compiled as 
a server extension module.

Andi


--
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] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Zeev Suraski]

At 10:39 08-08-01, Thies C. Arntzen wrote:
>On Wed, Aug 08, 2001 at 09:28:02AM +0200, Stig Sæther Bakken
>wrote:
> > [Zeev Suraski <[EMAIL PROTECTED]>]
> > > At 17:55 07-08-01, Stig Sæther Bakken wrote:
> > > >Now we're talking!  I assume it is not straightforward, what are the
> > > >technical challenges in doing JIT module initialization?
> > >
> > > It's not much of a challenge really.  If we decide it should be done,
> > > it can be done...
> >
> > Ok, so it's just a matter of "minit_done" and "rinit_done" properties
> > for each module?  Let's go for that, and either keep dl() or replace
> > it with php_load_extension() (the difference being that the latter
> > knows what file extension to use on your platform).
>
> sascha had a patch for this some time ago - the "gain" was
> near to zero. this might make sense once we "hit" the few
> hundred extension border...

Right.

Zeev


--
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] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Thies C. Arntzen]

On Wed, Aug 08, 2001 at 09:28:02AM +0200, Stig Sæther Bakken
wrote:
> [Zeev Suraski <[EMAIL PROTECTED]>]
> > At 17:55 07-08-01, Stig Sæther Bakken wrote:
> > >Now we're talking!  I assume it is not straightforward, what are the
> > >technical challenges in doing JIT module initialization?
> > 
> > It's not much of a challenge really.  If we decide it should be done,
> > it can be done...
> 
> Ok, so it's just a matter of "minit_done" and "rinit_done" properties
> for each module?  Let's go for that, and either keep dl() or replace
> it with php_load_extension() (the difference being that the latter
> knows what file extension to use on your platform).

sascha had a patch for this some time ago - the "gain" was
near to zero. this might make sense once we "hit" the few
hundred extension border...

tc

-- 
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] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Stig Sæther Bakken]

[Zeev Suraski <[EMAIL PROTECTED]>]
> At 17:55 07-08-01, Stig Sæther Bakken wrote:
> >Now we're talking!  I assume it is not straightforward, what are the
> >technical challenges in doing JIT module initialization?
> 
> It's not much of a challenge really.  If we decide it should be done,
> it can be done...

Ok, so it's just a matter of "minit_done" and "rinit_done" properties
for each module?  Let's go for that, and either keep dl() or replace
it with php_load_extension() (the difference being that the latter
knows what file extension to use on your platform).

 - Stig

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
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] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Zeev Suraski]

At 17:55 07-08-01, Stig Sæther Bakken wrote:
>Now we're talking!  I assume it is not straightforward, what are the
>technical challenges in doing JIT module initialization?

It's not much of a challenge really.  If we decide it should be done, it 
can be done...

Zeev


--
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] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Stig Sæther Bakken]

[Zeev Suraski <[EMAIL PROTECTED]>]
> At 19:40 06/08/2001, Andrei Zmievski wrote:
> >On Mon, 06 Aug 2001, Zeev Suraski wrote:
> > > At 07:10 06/08/2001, Sterling Hughes wrote:
> > > > What if you use 50 different shared extensions, for different
> > > > scripts on the same box? Should you load them all in each time?
> > > > I don't think so...
> > >
> > > Other than your phobia, there's no real reason not to do it :)
> >
> >No performance hit at all?
> 
> Nothing measurable.  That was actually measured (changing PHP to
> initialize extensions just-in-time, in case they're actually being
> used) - and it turned out it wasn't giving any noticeable performance
> gain.
> 
> If there were a thousand extensions, we may have to rethink it - but
> the good solution would probably be JIT initialization.

Now we're talking!  I assume it is not straightforward, what are the
technical challenges in doing JIT module initialization?

 - Stig

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
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] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Zeev Suraski]

I disagree in two levels.  First, I think that saying "We can't protect 
people from their stupidity, so let's lift all bars" is just plain wrong 
and a bad approach in a real world situation.  Sure, it's true, but we can 
definitely reduce the risks involved in common mistakes that people 
make.  Not bulletproof, but sometimes simply hinting people not to go 
around places where shots are fired is good enough.

On the second level, there are several other reasons not to keep dl() which 
aren't related to security or preventing people from doing the wrong 
things.  These are:
- Slow performance, encourages slow app writing
- Complicates the development of extensions and the engine
- Will not work in thread safe mode

All in all, dl() is simply bad, in just about every level.

Zeev

At 00:03 07-08-01, George Schlossnagle wrote:
> > In a few words:
> > For a webserver: ban dl()
> > For generic scripting: keep dl()
>
>What's really the point of protecting people from their stupidity.  If
>you're going to keep it in the generic scripting engine (which I think has
>lots of value), why not keep it in the webserver engine as well. There are
>plenty of php extensions which, imho, operate way to slow to called on a
>busy production site.  Does that mean they should be eliminated?  No, it
>means they should just be used with a 'buyer-beware' mentality.
>
>George

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
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] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Zeev Suraski]

At 23:57 06-08-01, Sander Steffann wrote:
>Hi,
>
> > >Deprecate dl()? I think it's one of the most useful functions... :)
> >
> > How so?  I can understand that people get used to it, but it's really
> > bad.  extensions should be loaded in the php.ini file.  There's really no
> > good reason for using dl() over the php.ini method.
>
>I agree with you when we are talking about using PHP in a webserver.
>However, I am seeing more and more use of PHP as a generic scripting
>language. In this situation, I think dl() is very useful...
>
>Imagine a application written in PHP that has a 'special' extension. For
>example, an extension to access a scanner. You don't want this loaded
>everywhere, just in your scanner application, and certainly not in your
>webserver.

You can achieve the same goal using a command line entry.

Zeev


-- 
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] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[George Schlossnagle]

> In a few words:
> For a webserver: ban dl()
> For generic scripting: keep dl()

What's really the point of protecting people from their stupidity.  If
you're going to keep it in the generic scripting engine (which I think has
lots of value), why not keep it in the webserver engine as well. There are
plenty of php extensions which, imho, operate way to slow to called on a
busy production site.  Does that mean they should be eliminated?  No, it
means they should just be used with a 'buyer-beware' mentality.

George



-- 
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] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Sander Steffann]

Hi,

> >Deprecate dl()? I think it's one of the most useful functions... :)
>
> How so?  I can understand that people get used to it, but it's really
> bad.  extensions should be loaded in the php.ini file.  There's really no
> good reason for using dl() over the php.ini method.

I agree with you when we are talking about using PHP in a webserver.
However, I am seeing more and more use of PHP as a generic scripting
language. In this situation, I think dl() is very useful...

Imagine a application written in PHP that has a 'special' extension. For
example, an extension to access a scanner. You don't want this loaded
everywhere, just in your scanner application, and certainly not in your
webserver.

In a few words:
For a webserver: ban dl()
For generic scripting: keep dl()

Sander.




-- 
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] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Andrei Zmievski]

On Mon, 06 Aug 2001, Zeev Suraski wrote:
> I think the disk weights about the same regardless of the data inside it
> :)

Yes, but 50 extensions will consume more memory than 1.

-Andrei

"In My Egotistical Opinion, most people's C programs should be indented
six feet downward and covered with dirt." -- Blair P. Houghton

-- 
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] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Zeev Suraski]

At 19:45 06/08/2001, Andrei Zmievski wrote:
>On Mon, 06 Aug 2001, Zeev Suraski wrote:
> > Nothing measurable.  That was actually measured (changing PHP to 
> initialize
> > extensions just-in-time, in case they're actually being used) - and it
> > turned out it wasn't giving any noticeable performance gain.
> >
> > If there were a thousand extensions, we may have to rethink it - but the
> > good solution would probably be JIT initialization.
>
>I have no problems with JIT-Init. We even have a marketable name for it,
>then. :)

:)
Anyway, I'm off for a few hours now, reinstalling my machine.  I'll answer 
anything that comes up when I get back ;)

Zeev


-- 
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] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Andrei Zmievski]

On Mon, 06 Aug 2001, Zeev Suraski wrote:
> Nothing measurable.  That was actually measured (changing PHP to initialize 
> extensions just-in-time, in case they're actually being used) - and it 
> turned out it wasn't giving any noticeable performance gain.
> 
> If there were a thousand extensions, we may have to rethink it - but the 
> good solution would probably be JIT initialization.

I have no problems with JIT-Init. We even have a marketable name for it,
then. :)

-Andrei
* Marriage is not a word. It's a sentence. Life-long sentence. *

-- 
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] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Zeev Suraski]

At 19:40 06/08/2001, Andrei Zmievski wrote:
>On Mon, 06 Aug 2001, Zeev Suraski wrote:
> > At 07:10 06/08/2001, Sterling Hughes wrote:
> > > What if you use 50 different shared extensions, for different
> > > scripts on the same box? Should you load them all in each time?
> > > I don't think so...
> >
> > Other than your phobia, there's no real reason not to do it :)
>
>No performance hit at all?

Nothing measurable.  That was actually measured (changing PHP to initialize 
extensions just-in-time, in case they're actually being used) - and it 
turned out it wasn't giving any noticeable performance gain.

If there were a thousand extensions, we may have to rethink it - but the 
good solution would probably be JIT initialization.

Zeev


-- 
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] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Andrei Zmievski]

On Mon, 06 Aug 2001, Zeev Suraski wrote:
> At 07:10 06/08/2001, Sterling Hughes wrote:
> > What if you use 50 different shared extensions, for different
> > scripts on the same box? Should you load them all in each time?
> > I don't think so...
> 
> Other than your phobia, there's no real reason not to do it :)

No performance hit at all?

-Andrei
* Life may be expensive, but it includes an annual free trip around the sun. *

-- 
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] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Zeev Suraski]

At 07:10 06/08/2001, Sterling Hughes wrote:
> What if you use 50 different shared extensions, for different
> scripts on the same box? Should you load them all in each time?
> I don't think so...

Other than your phobia, there's no real reason not to do it :)

Zeev


-- 
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-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Zeev Suraski]

At 19:29 06/08/2001, Andrei Zmievski wrote:
>On Mon, 06 Aug 2001, Zeev Suraski wrote:
> > By the way, I can't really quantify significantly, as it depends on what
> > kind of minit you have.  For a module such as the COM module, it can 
> double
> > the amount of time it takes the script to run (if you load typelibs).  For
> > some other modules, it can be almost anything, if your minit is mostly
> > empty.  As a general rule, it's a bad thing, since it repeats things which
> > don't have to be repeated.
>
>I thought you meant "significantly" worse run-time perfomance because
>the engine can't optimize for function arguments, not because of what
>kind of MINIT an extension has. We're still talking about standalone PHP
>binary here.

Ah.  Well, YMMV.  If you have repeated calls to functions (not class 
methods, these are not optimized), it can be quite significant - you have 
an extra opcode that includes some stack manipulation, string duplication 
and strtolower of the function name, and slower pass_param opcodes.  I 
never actually benchmarked it, but it can be quite significant.

Zeev


-- 
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-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Andrei Zmievski]

On Mon, 06 Aug 2001, Zeev Suraski wrote:
> By the way, I can't really quantify significantly, as it depends on what 
> kind of minit you have.  For a module such as the COM module, it can double 
> the amount of time it takes the script to run (if you load typelibs).  For 
> some other modules, it can be almost anything, if your minit is mostly 
> empty.  As a general rule, it's a bad thing, since it repeats things which 
> don't have to be repeated.

I thought you meant "significantly" worse run-time perfomance because
the engine can't optimize for function arguments, not because of what
kind of MINIT an extension has. We're still talking about standalone PHP
binary here.

-Andrei

A room without books is like a body without a soul.
  -- Marcus Tullius Cicero (106-43 B.C.)

-- 
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-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Zeev Suraski]

By the way, I can't really quantify significantly, as it depends on what 
kind of minit you have.  For a module such as the COM module, it can double 
the amount of time it takes the script to run (if you load typelibs).  For 
some other modules, it can be almost anything, if your minit is mostly 
empty.  As a general rule, it's a bad thing, since it repeats things which 
don't have to be repeated.


At 18:34 06/08/2001, Andrei Zmievski wrote:
>On Mon, 06 Aug 2001, Zeev Suraski wrote:
> > Drawbacks:
> > - It's slow.  We encourage putting expensive operations into the
> > module_init, using dl() means they end up being done multiple times.
> >
> > - Under Apache, it's even worse - since in addition to slowliness, it also
> > ends up consuming significantly more memory, since any memory the 
> extension
> > allocates in module_init (e.g., the function entries it registers) cannot
> > be shared between the processes.
>
>This doesn't apply under the standalone version, which is what I'm
>mainly worried about.
>
> > - It prevents the engine from optimizing function calls at compile 
> time, by
> > looking at what kind of arguments these functions expect.  This is left 
> for
> > run-time, which results in significantly slower run-time performance.
>
>Can you quantify "significantly"?
>
> > - Literally, none of the extensions properly cleans up after itself,
> > leaving PHP in various degrees of instability.  This rarely translates to
> > crashes, because people don't usually have a script in which they dl() and
> > then use a class, another script in which they use the class without
> > dl()'ing first, and call the 2nd script right after calling the 1st
> > one.  Still, from a cleanliness perspective and in theory, it's bad.
>
>I see. I wasn't aware that the extension was supposed to clean up the
>classes it registers. I will fix PHP-GTK behavior on this.
>
>-Andrei
>
>Linux is like living in a teepee.
>No Windows, no Gates, Apache in house.
> - Usenet signature

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
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] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Zeev Suraski]

At 06:30 06/08/2001, Sterling Hughes wrote:
>On Mon, 6 Aug 2001, Andrei Zmievski wrote:
>
> > On Mon, 06 Aug 2001, Zeev Suraski wrote:
> > > How so?  I can understand that people get used to it, but it's really
> > > bad.  extensions should be loaded in the php.ini file.  There's really no
> > > good reason for using dl() over the php.ini method.
> >
> > Of course there is. One example is using the same PHP binary to run
> > scripts that use different extensions that wouldn't necessarily want to
> > load all the time through php.ini.
> >
>
> Also, just to mention, right now it might not be that big a deal to
> load them all in php.ini (well something as big PHP-GTK would be,
> but...), however, as PHP gets more and more extensions written in C,
> there needs to be this functionality.

Why?  Whatever extension you use on your box, put them in the 
php.ini.  dl() is never a better option.

Zeev


-- 
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] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Andrei Zmievski]

On Mon, 06 Aug 2001, Thies C. Arntzen wrote:
> don't think there's an API for that. we would have to add the
> MODULE_NUMBER to the class-entry and then (when unloading the
> module) also destroy the classes that that module defined. i
> think constants and functions already do this.

Hmm, right, they don't have module_number..

-Andrei
* Why is it always Segmentation's fault? *

-- 
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-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Thies C. Arntzen]

On Mon, Aug 06, 2001 at 10:34:34AM -0500, Andrei Zmievski wrote:
> On Mon, 06 Aug 2001, Zeev Suraski wrote:
> > Drawbacks:
> > - It's slow.  We encourage putting expensive operations into the 
> > module_init, using dl() means they end up being done multiple times.
> > 
> > - Under Apache, it's even worse - since in addition to slowliness, it also 
> > ends up consuming significantly more memory, since any memory the extension 
> > allocates in module_init (e.g., the function entries it registers) cannot 
> > be shared between the processes.
> 
> This doesn't apply under the standalone version, which is what I'm
> mainly worried about.
> 
> > - It prevents the engine from optimizing function calls at compile time, by 
> > looking at what kind of arguments these functions expect.  This is left for 
> > run-time, which results in significantly slower run-time performance.
> 
> Can you quantify "significantly"?
> 
> > - Literally, none of the extensions properly cleans up after itself, 
> > leaving PHP in various degrees of instability.  This rarely translates to 
> > crashes, because people don't usually have a script in which they dl() and 
> > then use a class, another script in which they use the class without 
> > dl()'ing first, and call the 2nd script right after calling the 1st 
> > one.  Still, from a cleanliness perspective and in theory, it's bad.
> 
> I see. I wasn't aware that the extension was supposed to clean up the
> classes it registers. I will fix PHP-GTK behavior on this.

don't think there's an API for that. we would have to add the
MODULE_NUMBER to the class-entry and then (when unloading the
module) also destroy the classes that that module defined. i
think constants and functions already do this.

tc

-- 
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-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Andrei Zmievski]

On Mon, 06 Aug 2001, Zeev Suraski wrote:
> Drawbacks:
> - It's slow.  We encourage putting expensive operations into the 
> module_init, using dl() means they end up being done multiple times.
> 
> - Under Apache, it's even worse - since in addition to slowliness, it also 
> ends up consuming significantly more memory, since any memory the extension 
> allocates in module_init (e.g., the function entries it registers) cannot 
> be shared between the processes.

This doesn't apply under the standalone version, which is what I'm
mainly worried about.

> - It prevents the engine from optimizing function calls at compile time, by 
> looking at what kind of arguments these functions expect.  This is left for 
> run-time, which results in significantly slower run-time performance.

Can you quantify "significantly"?

> - Literally, none of the extensions properly cleans up after itself, 
> leaving PHP in various degrees of instability.  This rarely translates to 
> crashes, because people don't usually have a script in which they dl() and 
> then use a class, another script in which they use the class without 
> dl()'ing first, and call the 2nd script right after calling the 1st 
> one.  Still, from a cleanliness perspective and in theory, it's bad.

I see. I wasn't aware that the extension was supposed to clean up the
classes it registers. I will fix PHP-GTK behavior on this.

-Andrei

Linux is like living in a teepee.
No Windows, no Gates, Apache in house.
- Usenet signature

-- 
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] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Zeev Suraski]

See my letter to Andrei.

I've yet to see an ISP that (knowingly) allows users to load extensions, 
and wouldn't agree to add them to the php.ini file.

This isn't a case of me saying "users don't need X" or "95.6% of the 
scripts out there don't need Y".  This is me saying that dl() is *bad*, 
even if people got used to using it, which is why it should be 
deprecated.  Again, notice that it has been deprecated for a long while in 
thread-safe mode, which means people who develop under Windows (a huge 
share) don't have it for over a year.

dl() is bad in pretty much every sense, including the new sense you 
mentioned in your letter - dl()'ing extensions in a shared 
environment.  Forcing the ISP to admit any extensions into the php.ini file 
before it gets loaded to the server is a good thing.

If dl() is one of PEAR's foundations, it's time to dig it up and replace it 
with something more sound and stable :)  Using php.ini for loading 
extensions should be the way to go.

Zeev

At 18:18 06/08/2001, Stig Sæther Bakken wrote:
>[Zeev Suraski <[EMAIL PROTECTED]>]
> >
> > Please don't just say it's useful, please say why :)
> > dl() has absolutely nothing over loading in php.ini, and has many 
> drawbacks.
>
>Please allow me to coin a new term: "Zeev-ism".  Zeev-isms are of the
>form "users don't need X" or "95.6% of the scripts out there don't
>need Y". ;-)
>
>The fact is that a lot of people (typically ISP users) don't have
>access to php.ini or .htaccess.  If these people need a third party
>extension, or one that was not built in their ISP's version of PHP,
>they either have to get their ISP to include it (and if the ISP is big
>enough and the client small enough, they won't care), or use dl().  If
>their ISP hasn't disabled that function, in which case they're screwed
>anyway of course.
>
>I do get kinda worried when you pop out a statement like "we're
>probably going to deprecate dl() anyway", being able to load
>extensions at run-time sort of is one of PEAR's foundations.
>
>Let's try to fix these problems rather than cripping PHP.
>
>  - Stig
>
>--
>   Stig Sæther Bakken <[EMAIL PROTECTED]>
>   Fast Search & Transfer ASA, Trondheim, Norway

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


--
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-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Zeev Suraski]

At 18:07 06/08/2001, Andrei Zmievski wrote:
>On Mon, 06 Aug 2001, Zeev Suraski wrote:
> > BTW, there's no good reason not to load all of the extensions you may need
> > in all of your scripts from php.ini.  Loading many extensions doesn't pose
> > a significant/noticeable load.  Loading using dl() does.
>
>Can you explain why the difference matters?

Sure.  dl() means that module_init is done multiple times.  It also means 
that module_shutdown is done multiple times, *and* has to take care of 
cleaning up after the extension *completely*.  That is, clean whatever 
functions, classes, ini entries and callbacks this function may have 
registered.  Right now, only PHP functions and ini entries (to a degree) 
are handled properly.

Drawbacks:
- It's slow.  We encourage putting expensive operations into the 
module_init, using dl() means they end up being done multiple times.

- Under Apache, it's even worse - since in addition to slowliness, it also 
ends up consuming significantly more memory, since any memory the extension 
allocates in module_init (e.g., the function entries it registers) cannot 
be shared between the processes.

- It prevents the engine from optimizing function calls at compile time, by 
looking at what kind of arguments these functions expect.  This is left for 
run-time, which results in significantly slower run-time performance.

- Literally, none of the extensions properly cleans up after itself, 
leaving PHP in various degrees of instability.  This rarely translates to 
crashes, because people don't usually have a script in which they dl() and 
then use a class, another script in which they use the class without 
dl()'ing first, and call the 2nd script right after calling the 1st 
one.  Still, from a cleanliness perspective and in theory, it's bad.

- Another buglet resulting from this is the crash in debug mode, in case of 
a memory leak inside an extension, which is reported in the bugs db.  It's 
no biggy, but also has no good solution.

I don't think the solution should be fixing all of the extensions to clean 
up after themselves, when the only gain is having dl() work, and when using 
dl() is almost always(*) significantly worse than simply adding the 
extension to the php.ini file.

(*) I can't think of any case in which it isn't, but I'm staying humble :)

Zeev


-- 
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] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Stig Sæther Bakken]

[Zeev Suraski <[EMAIL PROTECTED]>]
> 
> Please don't just say it's useful, please say why :)
> dl() has absolutely nothing over loading in php.ini, and has many drawbacks.
 
Please allow me to coin a new term: "Zeev-ism".  Zeev-isms are of the
form "users don't need X" or "95.6% of the scripts out there don't
need Y". ;-)

The fact is that a lot of people (typically ISP users) don't have
access to php.ini or .htaccess.  If these people need a third party
extension, or one that was not built in their ISP's version of PHP,
they either have to get their ISP to include it (and if the ISP is big
enough and the client small enough, they won't care), or use dl().  If
their ISP hasn't disabled that function, in which case they're screwed
anyway of course.

I do get kinda worried when you pop out a statement like "we're
probably going to deprecate dl() anyway", being able to load
extensions at run-time sort of is one of PEAR's foundations.

Let's try to fix these problems rather than cripping PHP.

 - Stig

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
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-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Andrei Zmievski]

On Mon, 06 Aug 2001, Zeev Suraski wrote:
> BTW, there's no good reason not to load all of the extensions you may need 
> in all of your scripts from php.ini.  Loading many extensions doesn't pose 
> a significant/noticeable load.  Loading using dl() does.

Can you explain why the difference matters?

-Andrei

The church is near but the road is icy;
the bar is far away but I will walk carefully. -- Russian proverb

-- 
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-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Zeev Suraski]

BTW, there's no good reason not to load all of the extensions you may need 
in all of your scripts from php.ini.  Loading many extensions doesn't pose 
a significant/noticeable load.  Loading using dl() does.

Zeev

At 17:52 06/08/2001, Andrei Zmievski wrote:
>On Mon, 06 Aug 2001, Zeev Suraski wrote:
> > How so?  I can understand that people get used to it, but it's really
> > bad.  extensions should be loaded in the php.ini file.  There's really no
> > good reason for using dl() over the php.ini method.
>
>Of course there is. One example is using the same PHP binary to run
>scripts that use different extensions that wouldn't necessarily want to
>load all the time through php.ini.
>
>-Andrei
>
>When we eliminate the impossible, whatever remains,
>however improbable, must be true. -- Sherlock Holmes

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
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] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Zeev Suraski]

Please don't just say it's useful, please say why :)
dl() has absolutely nothing over loading in php.ini, and has many drawbacks.

Zeev

At 17:55 06/08/2001, Andy wrote:
>I disagree, is there any way dl() can be fixed,
>because it is a useful function...
>
>On Mon, 06 Aug 2001, Zeev Suraski wrote:
> > At 17:49 06/08/2001, Stig Sæther Bakken wrote:
> > >[Zeev Suraski <[EMAIL PROTECTED]>]
> > > > By the way, if it's really important, we can look into supporting it.
> > > > The way it was before - it worked in most cases (assuming you never
> > > > tried to use a class before you dl() the corresponding extension), but
> > > > could result in crashes in other cases.
> > > >
> > > > I don't think it's very important, though.  dl() should most probably
> > > > be deprecated from the language, as it's not supported in thread safe
> > > > mode, it's slow and insecure.  It also creates a host of interesting
> > > > bugs/buglets that are difficult to hunt and fix.  Other than that -
> > > > it's great :)
> > >
> > >Uhm, are you suggesting we take away the possibility of loading
> > >extensions at run-time?
> >
> > Depending on which run-time you mean, yes.  I don't think it should be
> > possible to load extensions from within a PHP script.
> >
> > Note that dl() never really behaved properly.  It was always broken to one
> > degree or another.  Also, it'll be completely unavailable in the thread
> > safe version of PHP, so we might as well deprecate it completely.
> > Loading extensions in the php.ini file is still very much possible.
> >
> > Zeev
> >
> >
> > --
> > 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]

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


--
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-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Zeev Suraski]

At 17:52 06/08/2001, Andrei Zmievski wrote:
>On Mon, 06 Aug 2001, Zeev Suraski wrote:
> > How so?  I can understand that people get used to it, but it's really
> > bad.  extensions should be loaded in the php.ini file.  There's really no
> > good reason for using dl() over the php.ini method.
>
>Of course there is. One example is using the same PHP binary to run
>scripts that use different extensions that wouldn't necessarily want to
>load all the time through php.ini.

That's one of the places where the PHP/Web functionality and a 
PHP-standalone functionality collide.  In a Web environment, it really 
makes no sense.

The right solution for that is most probably going to be adding a command 
line option that loads an extension (we already have that for Zend extensions).

Loading extensions from within a script is simply a pain to support, and it 
doesn't really give you anything.

Zeev


-- 
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] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Andy]

I disagree, is there any way dl() can be fixed,
because it is a useful function...

On Mon, 06 Aug 2001, Zeev Suraski wrote:
> At 17:49 06/08/2001, Stig Sæther Bakken wrote:
> >[Zeev Suraski <[EMAIL PROTECTED]>]
> > > By the way, if it's really important, we can look into supporting it.
> > > The way it was before - it worked in most cases (assuming you never
> > > tried to use a class before you dl() the corresponding extension), but
> > > could result in crashes in other cases.
> > >
> > > I don't think it's very important, though.  dl() should most probably
> > > be deprecated from the language, as it's not supported in thread safe
> > > mode, it's slow and insecure.  It also creates a host of interesting
> > > bugs/buglets that are difficult to hunt and fix.  Other than that -
> > > it's great :)
> >
> >Uhm, are you suggesting we take away the possibility of loading
> >extensions at run-time?
> 
> Depending on which run-time you mean, yes.  I don't think it should be 
> possible to load extensions from within a PHP script.
> 
> Note that dl() never really behaved properly.  It was always broken to one 
> degree or another.  Also, it'll be completely unavailable in the thread 
> safe version of PHP, so we might as well deprecate it completely.
> Loading extensions in the php.ini file is still very much possible.
> 
> Zeev
> 
> 
> --
> 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]

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Andrei Zmievski]

On Mon, 06 Aug 2001, Zeev Suraski wrote:
> How so?  I can understand that people get used to it, but it's really 
> bad.  extensions should be loaded in the php.ini file.  There's really no 
> good reason for using dl() over the php.ini method.

Of course there is. One example is using the same PHP binary to run
scripts that use different extensions that wouldn't necessarily want to
load all the time through php.ini.

-Andrei

When we eliminate the impossible, whatever remains,
however improbable, must be true. -- Sherlock Holmes

-- 
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] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Zeev Suraski]

At 17:49 06/08/2001, Stig Sæther Bakken wrote:
>[Zeev Suraski <[EMAIL PROTECTED]>]
> > By the way, if it's really important, we can look into supporting it.
> > The way it was before - it worked in most cases (assuming you never
> > tried to use a class before you dl() the corresponding extension), but
> > could result in crashes in other cases.
> >
> > I don't think it's very important, though.  dl() should most probably
> > be deprecated from the language, as it's not supported in thread safe
> > mode, it's slow and insecure.  It also creates a host of interesting
> > bugs/buglets that are difficult to hunt and fix.  Other than that -
> > it's great :)
>
>Uhm, are you suggesting we take away the possibility of loading
>extensions at run-time?

Depending on which run-time you mean, yes.  I don't think it should be 
possible to load extensions from within a PHP script.

Note that dl() never really behaved properly.  It was always broken to one 
degree or another.  Also, it'll be completely unavailable in the thread 
safe version of PHP, so we might as well deprecate it completely.
Loading extensions in the php.ini file is still very much possible.

Zeev


--
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-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Zeev Suraski]

At 17:42 06/08/2001, Andrei Zmievski wrote:
>On Mon, 06 Aug 2001, Zeev Suraski wrote:
> > By the way, if it's really important, we can look into supporting it.  The
> > way it was before - it worked in most cases (assuming you never tried to
> > use a class before you dl() the corresponding extension), but could result
> > in crashes in other cases.
> >
> > I don't think it's very important, though.  dl() should most probably be
> > deprecated from the language, as it's not supported in thread safe mode,
> > it's slow and insecure.  It also creates a host of interesting 
> bugs/buglets
> > that are difficult to hunt and fix.  Other than that - it's great :)
>
>Deprecate dl()? I think it's one of the most useful functions... :)

How so?  I can understand that people get used to it, but it's really 
bad.  extensions should be loaded in the php.ini file.  There's really no 
good reason for using dl() over the php.ini method.

Zeev


-- 
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] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Stig Sæther Bakken]

[Zeev Suraski <[EMAIL PROTECTED]>]
> By the way, if it's really important, we can look into supporting it.
> The way it was before - it worked in most cases (assuming you never
> tried to use a class before you dl() the corresponding extension), but
> could result in crashes in other cases.
> 
> I don't think it's very important, though.  dl() should most probably
> be deprecated from the language, as it's not supported in thread safe
> mode, it's slow and insecure.  It also creates a host of interesting
> bugs/buglets that are difficult to hunt and fix.  Other than that -
> it's great :)

Uhm, are you suggesting we take away the possibility of loading
extensions at run-time?

 - Stig

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
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-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Andrei Zmievski]

On Mon, 06 Aug 2001, Zeev Suraski wrote:
> By the way, if it's really important, we can look into supporting it.  The 
> way it was before - it worked in most cases (assuming you never tried to 
> use a class before you dl() the corresponding extension), but could result 
> in crashes in other cases.
> 
> I don't think it's very important, though.  dl() should most probably be 
> deprecated from the language, as it's not supported in thread safe mode, 
> it's slow and insecure.  It also creates a host of interesting bugs/buglets 
> that are difficult to hunt and fix.  Other than that - it's great :)

Deprecate dl()? I think it's one of the most useful functions... :)

-Andrei
* "Syntactic sugar causes cancer of the semicolon." -- Alan Perlis *

-- 
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] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Andrei Zmievski]

On Mon, 06 Aug 2001, Thies C. Arntzen wrote:
> i don't think this is crucial for the gtk stuff as this
> problem only arises once the request ends _and_ a new request
> starts. the shutdown in the engine has been changed to only
> destruct classes (from the end of the list) until the 1st
> internal class is found. so:
> 
>  class tubu {
> }
> dl("php-gtk");
> class hallo {
> }
> ?>
> 
> would (now) destruct class hallo but not tubu. zeev assured me that
> dl()'ing modules that created classes never "really" worked
> (it would always have request shutdown-trouble as the
> c-module would get unloaded but the class table would still
> point into the unloiaded module). i kinda don't like it, but
> i take zeevs word that it never worked properly. 

I haven't run into problems with it yet, but I'll keep this in mind, I
guess.

-Andrei
* http://www.zend.com/comm_person.php?id=24 *

-- 
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-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Zeev Suraski]

By the way, if it's really important, we can look into supporting it.  The 
way it was before - it worked in most cases (assuming you never tried to 
use a class before you dl() the corresponding extension), but could result 
in crashes in other cases.

I don't think it's very important, though.  dl() should most probably be 
deprecated from the language, as it's not supported in thread safe mode, 
it's slow and insecure.  It also creates a host of interesting bugs/buglets 
that are difficult to hunt and fix.  Other than that - it's great :)

Zeev

At 17:22 06/08/2001, Thies C. Arntzen wrote:
>On Mon, Aug 06, 2001 at 09:08:05AM -0500, Andrei Zmievski wrote:
> > On Mon, 06 Aug 2001, Thies C. Arntzen wrote:
> > > thies   Mon Aug  6 09:36:09 2001 EDT
> > >
> > >   Modified files:
> > > /php4/ext/standard  basic_functions.c incomplete_class.c
> > > php_incomplete_class.h var.c
> > > /php4/ext/wddx  wddx.c
> > >   Log:
> > >   we can no longer register internal-classes once the script is started.
> > >   therefore the "incomplete class" is now registered at MINIT time.
> >
> > How it's not possible all of a sudden?
>
> i don't think this is crucial for the gtk stuff as this
> problem only arises once the request ends _and_ a new request
> starts. the shutdown in the engine has been changed to only
> destruct classes (from the end of the list) until the 1st
> internal class is found. so:
>
>  class tubu {
> }
> dl("php-gtk");
> class hallo {
> }
> ?>
>
> would (now) destruct class hallo but not tubu. zeev assured me that
> dl()'ing modules that created classes never "really" worked
> (it would always have request shutdown-trouble as the
> c-module would get unloaded but the class table would still
> point into the unloiaded module). i kinda don't like it, but
> i take zeevs word that it never worked properly.
>
> tc

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
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-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Thies C. Arntzen]

On Mon, Aug 06, 2001 at 09:08:05AM -0500, Andrei Zmievski wrote:
> On Mon, 06 Aug 2001, Thies C. Arntzen wrote:
> > thies   Mon Aug  6 09:36:09 2001 EDT
> > 
> >   Modified files:  
> > /php4/ext/standard  basic_functions.c incomplete_class.c 
> > php_incomplete_class.h var.c 
> > /php4/ext/wddx  wddx.c 
> >   Log:
> >   we can no longer register internal-classes once the script is started. 
> >   therefore the "incomplete class" is now registered at MINIT time.
> 
> How it's not possible all of a sudden?

i don't think this is crucial for the gtk stuff as this
problem only arises once the request ends _and_ a new request
starts. the shutdown in the engine has been changed to only
destruct classes (from the end of the list) until the 1st
internal class is found. so:



would (now) destruct class hallo but not tubu. zeev assured me that
dl()'ing modules that created classes never "really" worked
(it would always have request shutdown-trouble as the
c-module would get unloaded but the class table would still
point into the unloiaded module). i kinda don't like it, but
i take zeevs word that it never worked properly. 

tc

-- 
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-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Andrei Zmievski]

On Mon, 06 Aug 2001, Thies C. Arntzen wrote:
> thies Mon Aug  6 09:36:09 2001 EDT
> 
>   Modified files:  
> /php4/ext/standardbasic_functions.c incomplete_class.c 
>   php_incomplete_class.h var.c 
> /php4/ext/wddxwddx.c 
>   Log:
>   we can no longer register internal-classes once the script is started. 
>   therefore the "incomplete class" is now registered at MINIT time.

How it's not possible all of a sudden?

-Andrei

"I think it would be a good idea." -- Mahatma Gandhi,
when asked what he thought of Western civilization...

-- 
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]