Question : threads and locking?

["Philippe M. Chiasson" <go...@cpan.org>]

Looking thru the todo/api.txt file, I noticed a few items that
are stuck in read-only mode, because thread locking is needed if
changing them.

I already have something in the works, but my question is that under
a non-threaded model, like prefork, all that is uesless, right? So,
what's the nice way for me to go on and write thread mutex stuff
that will only happen when running under threads ? 

My knoledge of the configure/build system is quite limited....

-- 
Philippe M. Chiasson  <go...@cpan.org>
  Extropia's Resident System Guru
     http://www.eXtropia.com/

/* When we have more time, we can teach the penguin to say 
  * "By your command" or "Activating turbo boost, Michael".
  */ 
	-- Linux	2.2.16
	/usr/src/linux/arch/sparc/prom/sun4prom.c

perl -e '$$=\${gozer};{$_=unpack(P26,pack(L,$$));/^Just Another Perl Hacker!\n$/&&print||$$++&&redo}'

Re: Question : threads and locking?

[Stas Bekman <st...@stason.org>]

Philippe M. Chiasson wrote:

> Looking thru the todo/api.txt file, I noticed a few items that
> are stuck in read-only mode, because thread locking is needed if
> changing them.
> 
> I already have something in the works, but my question is that under
> a non-threaded model, like prefork, all that is uesless, right? So,
> what's the nice way for me to go on and write thread mutex stuff
> that will only happen when running under threads ? 
> 
> My knoledge of the configure/build system is quite limited....


If you are running under threaded mpm, you can safely assume that Perl 
is threaded (won't pass the build otherwise). So no conditioning 
required fromt the Perl side.

Since the preforked mpm can actually be compiled with threaded apr, I think that's 

the only ifdef() required is:


#if APR_HAS_THREADS
     /* code here */
#endif

If the functionality is very different between forked and non-forked 
implementation, to avoid code cluttering with ifdefs, we probably should 
use two versions of the functions like foo_thr() and foo_nthr() and 
alias to foo() at compile time.

_____________________________________________________________________
Stas Bekman             JAm_pH      --   Just Another mod_perl Hacker
http://stason.org/      mod_perl Guide   http://perl.apache.org/guide
mailto:stas@stason.org  http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org

Re: Question : threads and locking?

[Doug MacEachern <do...@covalent.net>]

On Thu, 29 Nov 2001, Philippe M. Chiasson wrote:

> Looking thru the todo/api.txt file, I noticed a few items that
> are stuck in read-only mode, because thread locking is needed if
> changing them.
> 
> I already have something in the works, but my question is that under
> a non-threaded model, like prefork, all that is uesless, right? So,
> what's the nice way for me to go on and write thread mutex stuff
> that will only happen when running under threads ? 

you can decide at compile time if mutexes are supported (like your patch
does).   as for running in a threaded mpm, you'd have to decide at
runtime.  modperl sets up a the scfg->threaded_mpm variable for that.
there is also a modperl_global_threaded_mpm_get() function.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org

Re: Question : threads and locking?

[Doug MacEachern <do...@covalent.net>]

i forgot to point out the biggest problem: since all per-server data is
shared between threads, regardless of locking, changing the value of
something like ap_document_root changes it for all threads.  not just the
current process/request, the way it was in 1.3.
so we can't really support modification of things like ap_document_root at
request time, unless the mpm is prefork.  we could support modification
of modperl per-server data by using r->request_config in the same way
push_handlers etal. is implemented.  but it is not possible to use this
approach for anything outside of modperl (ap_document_root for example).




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org