Re: blead: new entry in the interperter for storing special contexts like ithreads?
On Fri, Jul 08, 2005 at 03:16:51PM +0300, Stas Bekman wrote: will it work w/o needing PERL_SET_CONTEXT(aTHX)? If we just make the first arg a ptr to an interpreter, then we can leave it to the caller how they get hold of my_perl. Most of the time we won't want perl_clone to do any cloning on it, since every new interpreter will want to set an explicit new value. so I'd think that perl_clone should always NULL it, no? in which case there is no need for a function (besides the identifier to find the entry in the linked list). In that case, your clone function can just set it to null. Other people's clone functions can do whatever they need. -- Britain, Britain, Britain! Discovered by Sir Henry Britain in sixteen-oh-ten. Sold to Germany a year later for a pfennig and the promise of a kiss. Destroyed in eighteen thirty-fourty two, and rebuilt a week later by a man. This we know. Hello. But what of the people of Britain? Who they? What do? And why? -- Little Britain
Re: blead: new entry in the interperter for storing special contexts like ithreads?
Dave Mitchell wrote: On Fri, Jul 08, 2005 at 03:16:51PM +0300, Stas Bekman wrote: will it work w/o needing PERL_SET_CONTEXT(aTHX)? If we just make the first arg a ptr to an interpreter, then we can leave it to the caller how they get hold of my_perl. +1 Most of the time we won't want perl_clone to do any cloning on it, since every new interpreter will want to set an explicit new value. so I'd think that perl_clone should always NULL it, no? in which case there is no need for a function (besides the identifier to find the entry in the linked list). In that case, your clone function can just set it to null. Other people's clone functions can do whatever they need. +1 -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
blead: new entry in the interperter for storing special contexts like ithreads?
At the moment ithreads.xs store the special ithreads struct in modglobal's magic, which is slow to get/set and it requires aTHX (setting of which again slows things down). mod_perl2 has the same needs and so far was using the unused HvPMROOT entry in HV which was recently nuked, and we don't want to significantly slow down the performance for 5.10 users in the threaded environment. I believe since we have at least 2 projects that require this functionality, the perl interpreter should have this functionality, instead of relying on the unused slots which can go away any moment as it was the case with HvPMROOT. Again the requirements is to have a plain pointer entry which is attached to each interpreter, but not touched by perl: 1) it should be set/get-able w/o requiring aTHX (or global context) 2) it must be not touched by perl (e.g. make perl_clone not touch it) we can start working with ithreads.xs to replace its Perl_ithread_set/get functions and then apply that to mod_perl2 as well. The solution is to just add a new entry to my_perl. The question is what happens if more than one project wants to use that entry? There is no collision at the moment since mod_perl2's interpeters aren't touched by ithreads and the other way around, but may be in the future there will be such a need? Thanks. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: blead: new entry in the interperter for storing special contexts like ithreads?
On Fri, Jul 08, 2005 at 02:07:13PM +0300, Stas Bekman wrote: 1) it should be set/get-able w/o requiring aTHX (or global context) 2) it must be not touched by perl (e.g. make perl_clone not touch it) we can start working with ithreads.xs to replace its Perl_ithread_set/get functions and then apply that to mod_perl2 as well. The solution is to just add a new entry to my_perl. But my_perl is just aTHX, so you *would* require aTHX (or dTHX). The question is what happens if more than one project wants to use that entry? There is no collision at the moment since mod_perl2's interpeters aren't touched by ithreads and the other way around, but may be in the future there will be such a need? How about (by analogy to mg), the new field in my_perl is a pointer to a linked list of structs that have 3 fields: data, fn, next data is a void * where you can put your private data; fn is a pointer to a function that is is called by perl_clone to clone the structure; it is also used as an identifier to disambiguate different users of the list. It would be wrapped in a simple API to add/delete an entry, or retrieve the data, eg PERL_INTERPRETER_DATA_ADD(data,my_func); data = PERL_INTERPRETER_DATA_GET(my_func); PERL_INTERPRETER_DATA_DELETE(my_func); -- I do not resent critisism, even when, for the sake of emphasis, it parts for the time with reality. -- Winston Churchill, House of Commons, 22nd Jan 1941.
Re: blead: new entry in the interperter for storing special contexts like ithreads?
Dave Mitchell wrote: On Fri, Jul 08, 2005 at 02:07:13PM +0300, Stas Bekman wrote: 1) it should be set/get-able w/o requiring aTHX (or global context) 2) it must be not touched by perl (e.g. make perl_clone not touch it) we can start working with ithreads.xs to replace its Perl_ithread_set/get functions and then apply that to mod_perl2 as well. The solution is to just add a new entry to my_perl. But my_perl is just aTHX, so you *would* require aTHX (or dTHX). sorry, I was talking about the interprter, not how it's accessed. e.g. Perl_Imodglobal_ptr(thx) requires no live perl context, all I need is a pointer to it. The question is what happens if more than one project wants to use that entry? There is no collision at the moment since mod_perl2's interpeters aren't touched by ithreads and the other way around, but may be in the future there will be such a need? How about (by analogy to mg), the new field in my_perl is a pointer to a linked list of structs that have 3 fields: data, fn, next data is a void * where you can put your private data; fn is a pointer to a function that is is called by perl_clone to clone the structure; it is also used as an identifier to disambiguate different users of the list. will it work w/o needing PERL_SET_CONTEXT(aTHX)? It would be wrapped in a simple API to add/delete an entry, or retrieve the data, eg PERL_INTERPRETER_DATA_ADD(data,my_func); data = PERL_INTERPRETER_DATA_GET(my_func); PERL_INTERPRETER_DATA_DELETE(my_func); Sounds good. Most of the time we won't want perl_clone to do any cloning on it, since every new interpreter will want to set an explicit new value. so I'd think that perl_clone should always NULL it, no? in which case there is no need for a function (besides the identifier to find the entry in the linked list). -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
