OK checked with Zeev. It seems there are some significant limitations at
least on Windows including that it doesn't work with LoadLibrary()
(which is our bread and butter).
There may also be some size limitations on thread local storage.
In any case, this is Windows-only feedback and we may find additional
limitations/compatibility issues on other platforms.

As there are clear benefits to an increased use of TLS (we already use
it for index caching today) I definitely suggest to revisit this issue
and try and figure out for the variety of platforms whether there's some
middle ground that we can make work. It sounds like a non-trivial
project though.
Arnaud, are you setup to also play around with Windows and possibly some
other OSes to look into this further?

Andi


> -----Original Message-----
> From: Arnaud Le Blanc [mailto:[EMAIL PROTECTED]
> Sent: Monday, August 18, 2008 10:00 PM
> To: Andi Gutmans
> Cc: PHP Development
> Subject: Re: [PHP-DEV] [PATCH] ZTS as fast as non-ZTS
> 
> Hi,
> 
> Yes, I have looked for the issue with --with-tsrm-full-__thread-tls
and there
> are effectively some issues.
> 
> When building PIC code, the used TLS model is a static model which
does not
> allow modules to be loaded at run-time. glibc's dlopen() sometimes
allow such
> code to be loaded at runtime when it finds some free memory, that's
why --
> with-
> tsrm-__thread-tls works, but it is not expected to always work.
> 
> So when building PIC code that's expected to work only when the
> server/application links the PHP module, or when using LD_PRELOAD,
etc.
> 
> Building non-PIC code allows to use a dynamic TLS model, which allows
to load
> modules a run-time, but it is less efficient (4.8s in bench.php, still
faster
> than unpatched version, even non-PIC, but less efficient).
> 
> Regards,
> 
> Arnaud
> 
> On Tuesday 19 August 2008 06:18:51 Andi Gutmans wrote:
> > Hi Arnaud,
> >
> > I remember that at the time we looked at thread local storage and
there
> > were some real issues with it. I can't remember what as it was about
7+
> > years ago.
> > I will ask Zeev if he remembers and if not search my archives (don't
> > have years prior to 2007 indexed :'( ).
> >
> > Andi
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Arnaud Le Blanc [mailto:[EMAIL PROTECTED]
> > > Sent: Saturday, August 16, 2008 7:19 PM
> > > To: PHP Development
> > > Subject: [PHP-DEV] [PATCH] ZTS as fast as non-ZTS
> > >
> > > Hi,
> > >
> > > Currently the way globals work forces to pass a
thread-local-storage
> > pointer
> > > across function calls, which involves some overhead. Also, not all
> > functions
> > > get the pointer as argument and need to use TSRMLS_FETCH(), which
is
> > slow. For
> > > instance emalloc() involves a TSRMLS_FETCH(). An other overhead is
> > accessing
> > > globals, using multiple pointers in different locations.
> > >
> > > The following patch caches each global address in a native TLS
> > variable so
> > > that accessing a global is as simple as global_name->member. This
> > removes the
> > > requirement of passing the tls pointer across function calls, so
that
> > the two
> > > major overheads of ZTS builds are avoided.
> > >
> > > Globals can optionally be declared statically, which speeds up
things
> > a bit.
> > >
> > > Results in bench.php:
> > > non-ZTS:                                          3.7s
> > > ZTS unpatched:                                    5.2s
> > > ZTS patched:                                      4.0s
> > > ZTS patched and static globals:   3.8s
> > >
> > > The patch introduces two new macros: TSRMG_D() (declare) and
> > TSRMG_DH()
> > > (declare, for headers) to declare globals, instead of the current
> > "ts_rsrc_id
> > > foo_global_id". These macros declare the global id, plus the
__thread
> > pointer
> > > to the global storage.
> > >
> > > ts_allocate_id now takes one more callback function as argument to
> > bind the
> > > global pointer to its storage. This callback is declared in
> > TSRMG_D[H]().
> > >
> > > As all TSRMLS_* macros now does nothing, it is needed to call
> > ts_resource(0)
> > > explicitly at least one time in each thread to initialize its
storage.
> > A new
> > > TSRMLS_INIT() macro as been added for this purpose.
> > >
> > > All this is disabled by default. --with-tsrm-__thread-tls enables
the
> > features
> > > of the patch, and --with-tsrm-full-__thread-tls enables static
> > declaration of
> > > globals.
> > >
> > > It as been tested on Linux compiled with --disable-all in CLI and
a
> > bit in
> > > Apache2 with the worker MPM. Known issues:
> > > - Declaring globals statically (--with-tsrm-full-__thread-tls)
causes
> > troubles
> > > to dlopen(), actually Apache wont load the module at runtime (it
works
> > with
> > > just --with-tsrm-__thread-tls).
> > > - The patch assumes that all resources are ts_allocate_id()'ed
before
> > any
> > > other thread calls ts_allocate_id or ts_resource_ex(), which is
> > possibly not
> > > the case.
> > >
> > > The patch needs some tweaks and does not pretend to be included in
any
> > branch,
> > > but I would like to have some comments on it.
> > >
> > > The patch: http://arnaud.lb.s3.amazonaws.com/__thread-tls.patch
> > >
> > > Regards,
> > >
> > > Arnaud
> > >
> > >
> > > --
> > > PHP Internals - PHP Runtime Development Mailing List
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >


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

Reply via email to