Re: mod_perl 2.x/perl 5.6.x ?
On Wed, Apr 26, 2000 at 01:32:29AM -0700, Doug MacEachern wrote:
> > Just tried it here and aside from some warnings it compiled and passed all
> > its tests. Can't say whether it works or not though as Msql-Mysql doesn't
> > compile, you got a patch hiding for that somewhere too :-)
>
> sure :) again, just compiles, not sure if it works.
>
> > PS: Mind if I post your message/patch on 'dbi-users' for Tim's benefit ?
>
> not at all, but i doubt either patch is quite right (the mysql one esp. is
> a quick hack)
Geez, I wasn't actually expecting a patch (just hoping maybe :-) and here
one is ! What can I say besides restating an earlier comment some else
posted recently "** You're the man **" !!
I don't know if the patches are quite right as you say, but both patches
(DBI, Msql-Mysql) compiled, passed their tests and after moving a couple
of scripts and databases over to the 'play' box they worked fine accessing
the mysql databases, displaying, inserting, and deleting records. Its just
a simple database-based GuestBook, nothing major but if its any indication
things appear to work fine with your patches.
I held off posting either of them to 'dbi-users' until I could do some
testing but since they seem to work I'm going to go ahead and post them
over there so the authors can take a peek, review, etc.
PS: I did find a patch Tim had posted for DBI, it didn't work for DBI but
it did work for Msql-Mysql. Looks like either your Msql-Mysql patch
or Tim's DBI patch work for Msql-Mysql, the common key seems to be
defining 'dbis', although they do it in different ways. I stuck with
your patches for both to keep things consistent. Tim's patch is below:
Index: DBI-1.1301/DBIXS.h
Prereq: 10.11
*** DBI-1.13/DBIXS.hMon Jul 12 03:04:28 1999
--- DBI-1.1301/DBIXS.h Tue Jul 13 23:01:22 1999
***
*** 1,4
! /* $Id: DBIXS.h,v 10.11 1999/07/12 02:02:33 timbo Exp $
*
* Copyright (c) 1994, 1995, 1996, 1997, 1998, 1999 Tim Bunce England
*
--- 1,4
! /* $Id: DBIXS.h,v 10.12 1999/07/13 22:01:12 timbo Exp $
*
* Copyright (c) 1994, 1995, 1996, 1997, 1998, 1999 Tim Bunce England
*
***
*** 397,407
# define DBISTATE_DECLARE
# define DBISTATE_INIT
! static dbistate_t * get_dbistate() {
! return ((dbistate_t*)SvIVX(DBISTATE_ADDRSV));
}
! # define DBIS (get_dbistate())
#else /* plain and simple non perl object / multiplicity case */
# define DBISTATE_DECLARE static dbistate_t *DBIS
--- 397,410
# define DBISTATE_DECLARE
# define DBISTATE_INIT
! static dbistate_t **get_dbistate() {
! return ((dbistate_t**)&SvIVX(DBISTATE_ADDRSV));
}
! # define DBIS (*get_dbistate())
+ /* temporary for drivers that mistakenly use 'dbis' instead of 'DBIS' */
+ # define dbis (*get_dbistate())
+
#else /* plain and simple non perl object / multiplicity case */
Re: mod_perl 2.x/perl 5.6.x ?
On Wed, 26 Apr 2000, Michael hall wrote:
> Just tried it here and aside from some warnings it compiled and passed all
> its tests. Can't say whether it works or not though as Msql-Mysql doesn't
> compile, you got a patch hiding for that somewhere too :-)
sure :) again, just compiles, not sure if it works.
> PS: Mind if I post your message/patch on 'dbi-users' for Tim's benefit ?
not at all, but i doubt either patch is quite right (the mysql one esp. is
a quick hack)
--- dbdimp.h~ Tue Jul 13 01:14:45 1999
+++ dbdimp.hWed Apr 26 01:27:57 2000
@@ -29,6 +29,10 @@
*/
#include /* installed by the DBI module*/
+#ifdef USE_ITHREADS
+#define dbis ((dbistate_t*)SvIVX(DBISTATE_ADDRSV))
+#endif
+
#include "myMsql.h"
--- dbdimp.c~ Sun Oct 10 05:08:11 1999
+++ dbdimp.cWed Apr 26 01:27:51 2000
@@ -373,7 +373,11 @@
**/
void dbd_init(dbistate_t* dbistate) {
+#ifdef USE_ITHREADS
+sv_setiv(DBISTATE_ADDRSV, (void*)dbistate);
+#else
DBIS = dbistate;
+#endif
}
Re: mod_perl 2.x/perl 5.6.x ?
On Tue, Apr 25, 2000 at 07:08:00PM -0700, Doug MacEachern wrote: > > The biggest hurdle I've faced until now is > > that DBI won't build with this threaded perl. Hopefully DBI will be updated > > since the latest version is from july 99. > > it compiles with the patch below, not sure if it actually works though :) Just tried it here and aside from some warnings it compiled and passed all its tests. Can't say whether it works or not though as Msql-Mysql doesn't compile, you got a patch hiding for that somewhere too :-) PS: Mind if I post your message/patch on 'dbi-users' for Tim's benefit ? -- I'm as confused as a baby in a topless bar. Mike Hall, Unix Admin - Rock Island Communications <[EMAIL PROTECTED]> System Admin - riverside.org<[EMAIL PROTECTED]>
RE: mod_perl 2.x/perl 5.6.x ?
On Sat, 22 Apr 2000, Eric Cholet wrote:
> mod_perl-2.0 requires perl 5.6 to be build with -Dusethreads, which turns
> on threading and multiplicity.
just to be clear, as you mention below, -Dusetheads isn't required for
mod_perl-2.0, but strongly suggested if you use an mpm other than prefork :)
and i wouldn't say -Dusethreads "turns on threading", it simply makes the
Perl runtime re-entrant (as explained in an earlier message)
> The biggest hurdle I've faced until now is
> that DBI won't build with this threaded perl. Hopefully DBI will be updated
> since the latest version is from july 99.
it compiles with the patch below, not sure if it actually works though :)
> This is for using Apache 2.0's pthread MPM, of course you can build perl
> 5.6 non threaded and use apache 2.0's prefork model but then it's not
> as exciting :-)
maybe not as exciting, but still very important, the 1.3.x model works
quite well for many people, so mod_perl-2.0 will continue to support it.
--- DBI.xs~ Sun Jul 11 19:04:27 1999
+++ DBI.xs Tue Apr 25 19:05:40 2000
@@ -9,6 +9,13 @@
#include "DBIXS.h" /* DBI public interface for DBD's written in C */
+#ifndef pTHX_
+#define aTHXo_
+#define CopFILEGV(cop) cop->cop_filegv
+#define CopLINE(cop) cop->cop_line
+#define get_sv perl_get_sv
+#endif
+
#define MY_VERSION "DBI(" XS_VERSION ")"
#if (defined USE_THREADS || defined PERL_CAPI || defined PERL_OBJECT)
@@ -112,7 +119,7 @@
# if (PATCHLEVEL == 4) && (SUBVERSION < 68)
# define dPERINTERP_SV \
-SV *perinterp_sv = perl_get_sv(MY_VERSION, FALSE)
+SV *perinterp_sv = get_sv(MY_VERSION, FALSE)
# else
# define dPERINTERP_SV \
SV *perinterp_sv = *hv_fetch(PL_modglobal, MY_VERSION, \
@@ -121,7 +128,7 @@
# define dPERINTERP_PTR(T,name)\
T name = (T)(perinterp_sv && SvIOK(perinterp_sv) \
- ? SvIVX(perinterp_sv) : NULL)
+ ? (T)SvIVX(perinterp_sv) : NULL)
# define dPERINTERP\
dPERINTERP_SV; dPERINTERP_PTR(PERINTERP_t *, PERINTERP)
# define INIT_PERINTERP \
@@ -189,13 +196,13 @@
DBIS->size= sizeof(*DBIS);
DBIS->xs_version = DBIXS_VERSION;
/* publish address of dbistate so dynaloaded DBD's can find it */
-sv_setiv(perl_get_sv(DBISTATE_PERLNAME,1), (IV)DBIS);
+sv_setiv(get_sv(DBISTATE_PERLNAME,1), (IV)DBIS);
DBISTATE_INIT; /* check DBD code to set DBIS from DBISTATE_PERLNAME*/
DBIS->logfp= stderr;
DBIS->debug= 0;
-DBIS->neatsvpvlen = perl_get_sv("DBI::neat_maxlen", GV_ADDMULTI);
+DBIS->neatsvpvlen = get_sv("DBI::neat_maxlen", GV_ADDMULTI);
sv_setiv(DBIS->neatsvpvlen, 400);
/* store some function pointers so DBD's can call our functions*/
DBIS->getcom= dbih_getcom;
@@ -613,7 +620,7 @@
if (imp_size == 0) {
/* get size of structure to allocate for common and imp specific data */
char *imp_size_name = mkvname(imp_stash, "imp_data_size", 0);
- imp_size = SvIV(perl_get_sv(imp_size_name, 0x05));
+ imp_size = SvIV(get_sv(imp_size_name, 0x05));
if (imp_size == 0)
imp_size = g_imp_maxsize + 64;
}
@@ -1450,16 +1457,16 @@
fprintf(logfp," during global destruction.");
return;
}
-if (!curcop->cop_line) {
+if (!CopLINE(curcop)) {
fprintf(logfp," at unknown location!");
return;
}
-file = SvPV(GvSV(curcop->cop_filegv), len);
+file = SvPV(GvSV(CopFILEGV(curcop)), len);
if (trace_level<=4) {
if ( (sep=strrchr(file,'/')) || (sep=strrchr(file,'\\')))
file = sep+1;
}
-fprintf(logfp," at %s line %ld.", file, (long)curcop->cop_line);
+fprintf(logfp," at %s line %ld.", file, (long)CopLINE(curcop));
}
@@ -1751,7 +1758,7 @@
*/
I32 markix = TOPMARK;
CV *xscv = GvCV(imp_msv);
- (void)(*CvXSUB(xscv))(xscv);/* Call the C code directly */
+ (void)(*CvXSUB(xscv))(aTHXo_ xscv); /* Call the C code directly */
if (gimme == G_SCALAR) {/* Enforce sanity in scalar context */
if (++markix != stack_sp - stack_base ) {
@@ -2130,7 +2137,7 @@
Fflush(DBILOGFP);
}
DBIS->debug = level;
- sv_setiv(perl_get_sv("DBI::dbi_debug",0x5), level);
+ sv_setiv(get_sv("DBI::dbi_debug",0x5), level);
}
}
OUTPUT:
@@ -2226,7 +2233,7 @@
}
if (type == '$') { /* lookup scalar variable in implementors stash */
char *vname = mkvname(DBIc_IMP_STASH(imp_xxh), meth, 0);
- SV *vsv = perl_get_sv(vname, 1);
+ SV *vsv = get_sv(vname, 1);
if (trace)
fprintf(DBILOGFP,"<- %s = %s\n", vname, neatsvpv(vsv,0));
ST(0) = sv_mortalcopy(vsv);
RE: mod_perl 2.x/perl 5.6.x ?
On Sun, 23 Apr 2000, Gunther Birznieks wrote: > I agree... but to some degree I hope this has been done for many of the > major modules and the major DBI modules (eg DBD sybase)... as they ended up > having to work on ActiveState's PerlEx which uses a similar model. In a > way, PerlEx's model has been a test for mod_perl 2.0. indeed. PerlEx uses PERL_OBJECT, which is similar in concept to USE_ITHREADS. we all owe a great deal of thanks to ActiveState for sponsoring Gurusamy Sarathy's work on 5.6.0. without the USE_ITHREADS implementation, mod_perl would be next to useless with threaded apache-2.0
Re: mod_perl 2.x/perl 5.6.x ?
On Sat, 22 Apr 2000, Leslie Mikesell wrote: > So, does that still leave mod_perl serializing access until > everything is rewritten to be thread-safe? no, -Dusethreads with 5.6.0 makes the Perl runtime (aka PerlInterpreter), re-entrant. all of Perl's internal globals (symbol table, stacks, etc.) become part of the PerlInterpreter structure, each interpreter clone has it's own copy of any writeable data (symbol table, stacks, etc.) the syntax tree is shared. this makes it possible to concurrently call subroutines in different threads, which was not possible with 5.005_03. this doesn't solve the problem of xs modules or c libraries that are not thread-safe, we'll have to fix any trouble makers as they pop up.
RE: mod_perl 2.x/perl 5.6.x ?
> > In the end, there may still be some threading issues that should > be watched > out for I suspect. If mod_perl 2.0 follows a similar design to > ActiveState's PerlEx, PerlEx also has some problems when the Perl modules > themselves link to stuff that is not threadsafe as a shared library. > Yes, this will make of course trouble :-(, but this at least limits the problem to modules which links to non thread safe libraries (which could be anything the uses XS and therefor is more then I initialy thought). Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925151 WWW:http://www.ecos.de Fax: +49 6133 925152 -
RE: mod_perl 2.x/perl 5.6.x ?
At 09:59 AM 4/23/00 -0700, Jeffrey W. Baker wrote: >On Sun, 23 Apr 2000, Gerald Richter wrote: > > > > > > > So, does that still leave mod_perl serializing access until > > > everything is rewritten to be thread-safe? > > > > > > > No, mod_perl 2.0 assign a "full" Perl interpreter to every Apache > thread. So > > the Perl modules itself need not to be thread safe. Perl 5.6 has some nice > > features to clone a Perl interpreter in a efficent way (syntax tree of > > modules (loaded before clone) is used by all cloned Perl interpreters, > while > > the data is separate for all cloned Perl interpreters). mod_perl 2.0 get > > manages a pool of cloned Perl interpreters which is assigns as > neccessary to > > the Apache threads. > >I suspect that two things are going to happen here. The CPAN community is >going to have to turn the crank one more time to update popular modules to >work under this environment. DBI and its drivers are going to be >particularly important. Secondly, this Perl environment is going to >reveal things that people never considered doing before, and some new and >useful modules will be added to our arsenal. I agree... but to some degree I hope this has been done for many of the major modules and the major DBI modules (eg DBD sybase)... as they ended up having to work on ActiveState's PerlEx which uses a similar model. In a way, PerlEx's model has been a test for mod_perl 2.0. Caveat to my statement: I am not a Perl internals guru. So what I say is conjecture and hope rather than what will definately happen when mod_perl 2.0 comes out. Later, Gunther
RE: mod_perl 2.x/perl 5.6.x ?
On Sun, 23 Apr 2000, Gerald Richter wrote: > > > > So, does that still leave mod_perl serializing access until > > everything is rewritten to be thread-safe? > > > > No, mod_perl 2.0 assign a "full" Perl interpreter to every Apache thread. So > the Perl modules itself need not to be thread safe. Perl 5.6 has some nice > features to clone a Perl interpreter in a efficent way (syntax tree of > modules (loaded before clone) is used by all cloned Perl interpreters, while > the data is separate for all cloned Perl interpreters). mod_perl 2.0 get > manages a pool of cloned Perl interpreters which is assigns as neccessary to > the Apache threads. I suspect that two things are going to happen here. The CPAN community is going to have to turn the crank one more time to update popular modules to work under this environment. DBI and its drivers are going to be particularly important. Secondly, this Perl environment is going to reveal things that people never considered doing before, and some new and useful modules will be added to our arsenal. But first, Apache 2.0 will need to get out the door. -jwb
RE: mod_perl 2.x/perl 5.6.x ?
At 02:51 PM 4/23/00 +0200, Gerald Richter wrote: > > > > So, does that still leave mod_perl serializing access until > > everything is rewritten to be thread-safe? > > > >No, mod_perl 2.0 assign a "full" Perl interpreter to every Apache thread. So >the Perl modules itself need not to be thread safe. Perl 5.6 has some nice >features to clone a Perl interpreter in a efficent way (syntax tree of >modules (loaded before clone) is used by all cloned Perl interpreters, while >the data is separate for all cloned Perl interpreters). mod_perl 2.0 get >manages a pool of cloned Perl interpreters which is assigns as neccessary to >the Apache threads. In the end, there may still be some threading issues that should be watched out for I suspect. If mod_perl 2.0 follows a similar design to ActiveState's PerlEx, PerlEx also has some problems when the Perl modules themselves link to stuff that is not threadsafe as a shared library. eg, every 2 weeks or so, the PerlEx mailing list has someone post "I get mysterious crashes with Win32::ODBC"... and the perennial reply of "Don't use that module with PerlEx as it's not threadsafe"... I don't know if there is anything else that might cause a similar problem. Later, Gunther
RE: mod_perl 2.x/perl 5.6.x ?
> > So, does that still leave mod_perl serializing access until > everything is rewritten to be thread-safe? > No, mod_perl 2.0 assign a "full" Perl interpreter to every Apache thread. So the Perl modules itself need not to be thread safe. Perl 5.6 has some nice features to clone a Perl interpreter in a efficent way (syntax tree of modules (loaded before clone) is used by all cloned Perl interpreters, while the data is separate for all cloned Perl interpreters). mod_perl 2.0 get manages a pool of cloned Perl interpreters which is assigns as neccessary to the Apache threads. Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925151 WWW:http://www.ecos.de Fax: +49 6133 925152 -
Re: mod_perl 2.x/perl 5.6.x ?
According to Eric Cholet: > > > > Does apache 2.0 let you run a prefork model under NT? > > > NT has it's own MPM which is threaded > > prefork ... Multi Process Model with Preforking (Apache 1.3) > dexter Multi Process Model with Threading via Pthreads > Constant number of processes, variable number of threads > mpmt_pthread .. Multi Process Model with Threading via Pthreads > Variable number of processes, constant number of > threads/child (= Apache/pthread) > spmt_os2 .. Single Process Model with Threading on OS/2 > winnt . Single Process Model with Threading on Windows NT > > I believe the first 3 run only under Unix. So, does that still leave mod_perl serializing access until everything is rewritten to be thread-safe? Les Mikesell [EMAIL PROTECTED]
Re: mod_perl 2.x/perl 5.6.x ?
On Sat, Apr 22, 2000 at 11:59:58AM +0200, Eric Cholet wrote: > > though. Can anybody in the know, shed some light on this, just trying to > > save some work down the road as I'd like to upgrade to the perl 5.6 stuff > > now and use it with my existing mod_perl (I already use the CVS version > > and I know thats required for perl 5.6) but I really don't want to have > > recompile perl (and modules, etc) again later if I can build it the way > > it will need to be now and continue using mod_perl 1.x and then just upgrade > > to mod_perl 2.x down the road. > > mod_perl-2.0 requires perl 5.6 to be build with -Dusethreads, which turns > on threading and multiplicity. The biggest hurdle I've faced until now is > that DBI won't build with this threaded perl. Hopefully DBI will be updated > since the latest version is from july 99. > This is for using Apache 2.0's pthread MPM, of course you can build perl > 5.6 non threaded and use apache 2.0's prefork model but then it's not > as exciting :-) Thinking about it now after your message and it makes sense. I've actually been a bit lazy and still have one of the older CVS versions (pre alpha) of Apache 2.0, guess I don't know about the alphas but I was playing with both the threaded, dexter MPM's. Since dexter is kind of a hybrid but uses threads I assume it'll also need a threaded perl then. At one time I did build a threaded perl but ran into problems here and there with various modules, etc. Don't recall having any problems with DBI but then again it wasn't perl 5.6 either, that is kind of a show stopper though :-( All in all I guess I found out the answer, might just as well go for it and build 5.6 threaded, grab the lastest Apache 2.x alpha and take what comes. Its my play box anyways so I guess I can live with some things being broken :-) -- Didn't I see your picture on a milk carton ? Mike Hall, Unix Admin - Rock Island Communications <[EMAIL PROTECTED]> System Admin - riverside.org<[EMAIL PROTECTED]>
RE: mod_perl 2.x/perl 5.6.x ?
> > This is for using Apache 2.0's pthread MPM, of course you can build perl > > 5.6 non threaded and use apache 2.0's prefork model but then it's not > > as exciting :-) > > Does apache 2.0 let you run a prefork model under NT? NT has it's own MPM which is threaded prefork ... Multi Process Model with Preforking (Apache 1.3) dexter Multi Process Model with Threading via Pthreads Constant number of processes, variable number of threads mpmt_pthread .. Multi Process Model with Threading via Pthreads Variable number of processes, constant number of threads/child (= Apache/pthread) spmt_os2 .. Single Process Model with Threading on OS/2 winnt . Single Process Model with Threading on Windows NT I believe the first 3 run only under Unix. -- Eric
Re: mod_perl 2.x/perl 5.6.x ?
According to Eric Cholet: > > This is for using Apache 2.0's pthread MPM, of course you can build perl > 5.6 non threaded and use apache 2.0's prefork model but then it's not > as exciting :-) Does apache 2.0 let you run a prefork model under NT? Les Mikesell [EMAIL PROTECTED]
RE: mod_perl 2.x/perl 5.6.x ?
> I'm more of a perl end user and plead ignorance in actually understanding > what goes on behind the scenes. In the process of considering upgrading to > perl 5.6 and according to a recent message I see its going to be required > for mod_perl 2.x anyways so I guess its a good time to start migrating in that > direction. I was curious as to if there are requirements as to how perl > should be built for this. I scanned through the archives as I seemed to > remember some threads about this awhile ago, especially regarding threads > and multiplicity, from what I can see it looks like -DMULTIPLICITY is > going to be required ?, don't know about -DTHREADS, doesn't look like it > though. Can anybody in the know, shed some light on this, just trying to > save some work down the road as I'd like to upgrade to the perl 5.6 stuff > now and use it with my existing mod_perl (I already use the CVS version > and I know thats required for perl 5.6) but I really don't want to have > recompile perl (and modules, etc) again later if I can build it the way > it will need to be now and continue using mod_perl 1.x and then just upgrade > to mod_perl 2.x down the road. mod_perl-2.0 requires perl 5.6 to be build with -Dusethreads, which turns on threading and multiplicity. The biggest hurdle I've faced until now is that DBI won't build with this threaded perl. Hopefully DBI will be updated since the latest version is from july 99. This is for using Apache 2.0's pthread MPM, of course you can build perl 5.6 non threaded and use apache 2.0's prefork model but then it's not as exciting :-) -- Eric
mod_perl 2.x/perl 5.6.x ?
I'm more of a perl end user and plead ignorance in actually understanding what goes on behind the scenes. In the process of considering upgrading to perl 5.6 and according to a recent message I see its going to be required for mod_perl 2.x anyways so I guess its a good time to start migrating in that direction. I was curious as to if there are requirements as to how perl should be built for this. I scanned through the archives as I seemed to remember some threads about this awhile ago, especially regarding threads and multiplicity, from what I can see it looks like -DMULTIPLICITY is going to be required ?, don't know about -DTHREADS, doesn't look like it though. Can anybody in the know, shed some light on this, just trying to save some work down the road as I'd like to upgrade to the perl 5.6 stuff now and use it with my existing mod_perl (I already use the CVS version and I know thats required for perl 5.6) but I really don't want to have recompile perl (and modules, etc) again later if I can build it the way it will need to be now and continue using mod_perl 1.x and then just upgrade to mod_perl 2.x down the road. Thanks, -- A person is not old until regrets take the place of dreams. Mike Hall, Unix Admin - Rock Island Communications <[EMAIL PROTECTED]> System Admin - riverside.org<[EMAIL PROTECTED]>
