Re: [VOTE] accept mod_macro as standard module in httpd

2013-01-05 Thread Igor Galić
+1 - Original Message - > I was preparing the IP clearance forms and noticed our original > "vote" > thread was more of a discussion. I wanted to record a formal vote > here > so I can link to it. > > Pending IP clearance... > > [+1] accept mod_macro as a standard module and responsibili

Re: [users@httpd] SSL, SNI and SSLStrictSNIVHostCheck

2013-01-05 Thread Igor Galić
Thomas, I think the users@ list may be the wrong target for such discussion. FWDing to dev@ - Original Message - > Is the directive > SSLStrictSNIVHostCheck On > meant to block connections to a virtual host if the connecting > client > uses an IP literal as URL ? RFC 6066 states t

Re: [VOTE] accept mod_macro as standard module in httpd

2013-01-05 Thread 松本 亮介
+1 it's awesome! MATSUMOTO Ryosuke < matsu1229 at gmail.com > http://blog.matsumoto-r.jp/ On 2013/01/05, at 18:30, Igor Galić wrote: > +1 > > - Original Message - >> I was preparing the IP clearance forms and noticed our original >> "vote" >> thread was more of a discussion. I wa

Re: [Discuss] mod_lua and database connectivity

2013-01-05 Thread Igor Galić
> Implied semantics matter a LOT in API design. +1 > > > > Check your errors :-) > I don't need to check errors, I just need to check whether 'rows' is > a > table or a nil value in the case of an error. I could've checked if > 'err' was anything, but the result is the same. > > An API which

Re: Password caching (was: svn commit: r1427548)

2013-01-05 Thread Igor Galić
- Original Message - > On Wednesday 02 January 2013, Eric Covener wrote: > > On Wed, Jan 2, 2013 at 4:02 PM, Stefan Fritsch > wrote: > > > On Wednesday 02 January 2013, Jim Jagielski wrote: > > >> For *real* improvement, wouldn't storing in socache be > > >> the optimal method? > > > >

Re: [VOTE] accept mod_macro as standard module in httpd

2013-01-05 Thread Christophe JAILLET
Le 03/01/2013 03:06, Eric Covener a écrit : I was preparing the IP clearance forms and noticed our original "vote" thread was more of a discussion. I wanted to record a formal vote here so I can link to it. Pending IP clearance... [+1] accept mod_macro as a standard module and responsibility fo

Re: thread-safety of time conversion caches in util_time.c and mod_log_config.c

2013-01-05 Thread Stefan Fritsch
On Saturday 05 January 2013, Daniel Lescohier wrote: > apr_atomic_read32 is not implemented with a memory barrier. The > implementation of apr_atomic_read32 in the APR code base is just a > read from a pointer marked volatile. E.g., here is the > atomic/unix/builtins.c implementation: > > APR_DE

Re: thread-safety of time conversion caches in util_time.c and mod_log_config.c

2013-01-05 Thread Igor Galić
- Original Message - > On Saturday 05 January 2013, Daniel Lescohier wrote: > > apr_atomic_read32 is not implemented with a memory barrier. The > > implementation of apr_atomic_read32 in the APR code base is just a > > read from a pointer marked volatile. E.g., here is the > > atomic/un

Re: thread-safety of time conversion caches in util_time.c and mod_log_config.c

2013-01-05 Thread Igor Galić
> > Sigh. I was too much focused on x86. There the compiler barrier > > caused > > by the function call is enough. But you are right, on other > > architectures these functions may also require cpu memory barriers. > > " on x86 … is enough" - would it harm x86 to add CPU barriers, or > do we want

Re: [Discuss] mod_lua and database connectivity

2013-01-05 Thread Daniel Gruno
On 01/05/2013 10:49 AM, Igor Galić wrote: > >> Implied semantics matter a LOT in API design. > > +1 > >>> >>> Check your errors :-) >> I don't need to check errors, I just need to check whether 'rows' is >> a >> table or a nil value in the case of an error. I could've checked if >> 'err' was an

Re: Password caching (was: svn commit: r1427548)

2013-01-05 Thread Stefan Fritsch
On Saturday 05 January 2013, Igor Galić wrote: > > No, mod_authn_socache only caches the lookup of the password > > hash. It avoids having to open the password file/dbm/whatever > > but it still calls apr_password_validate() every time. Maybe it > > should be extended to also cache the real passwor

Re: event mpm and mod_status

2013-01-05 Thread Graham Leggett
On 05 Jan 2013, at 2:05 AM, Stefan Fritsch wrote: > For 1., a better thread selection would definitely be a win. For 2. > and 3., it is less obvious. +1. Just because in some cases a cache might not help, doesn't mean we shouldn't take advantage of the cache when it will help. Regards, Graha

Re: thread-safety of time conversion caches in util_time.c and mod_log_config.c

2013-01-05 Thread Daniel Lescohier
I'd have to go back and review the Intel documentation to be sure, but for this particular algorithm, an explicit memory barrier may be required on Intel architecture, also. If I remember correctly, without a memory barrier, Intel arch only guarantees total memory ordering within one cache line.

Re: event mpm and mod_status

2013-01-05 Thread Jim Jagielski
+1... a lot of little improvements can result in a BIG improvement. On Jan 5, 2013, at 8:34 AM, Graham Leggett wrote: > On 05 Jan 2013, at 2:05 AM, Stefan Fritsch wrote: > >> For 1., a better thread selection would definitely be a win. For 2. >> and 3., it is less obvious. > > +1. > > Just

Re: Balancer persist and inherit stuff in trunk

2013-01-05 Thread Jim Jagielski
I haven't created the patch yet... it seems backwards to generate a backport patchset unless what is currently in trunk is OK. There were some suggestions for improvement made regarding the 2.4 backport that ideally would have been noted and addressed in trunk first. I just want to avoid another go

Re: Balancer persist and inherit stuff in trunk

2013-01-05 Thread Mikhail T.
On 05.01.2013 10:30, Jim Jagielski wrote: I haven't created the patch yet... it seems backwards to generate a backport patchset unless what is currently in trunk is OK. I can drop in a patch into our 2.4.3 build relatively easily. Building (and testing) from trunk is a more serious undertaking.

Re: Balancer persist and inherit stuff in trunk

2013-01-05 Thread Rainer Jung
On 04.01.2013 19:48, Jim Jagielski wrote: > Have people had a chance to test, review and try the balancer > persist and inheritance stuff in trunk? I want to make > sure that we have some level of verification and agreement > there before I work on the backports for 2.4 ;) I didn't see any changes

Re: [VOTE] accept mod_macro as standard module in httpd

2013-01-05 Thread Daniel Ruggeri
On 1/2/2013 8:06 PM, Eric Covener wrote: > I was preparing the IP clearance forms and noticed our original "vote" > thread was more of a discussion. I wanted to record a formal vote here > so I can link to it. > > Pending IP clearance... > > [+1] accept mod_macro as a standard module and responsibi

Re: [Discuss] mod_lua and database connectivity

2013-01-05 Thread Sean Conner
It was thus said that the Great Daniel Gruno once stated: > With regards to how :query should work, this could either be done > synchronously, wherein all rows are fetched at once, or async where rows > are fetched as needed. The sync way is rather easy, but could fill up > more memory than needed,

Re: thread-safety of time conversion caches in util_time.c and mod_log_config.c

2013-01-05 Thread Daniel Lescohier
I was wrong about the Intel architecture: it has a pretty strong memory-ordering guarantee. But other architectures, like PowerPC and ARM, have a weak memory-ordering guarantee. Here is a good summary: https://en.wikipedia.org/wiki/Memory_ordering. The doc in footnote 3 is a good document to rea

Re: Password caching

2013-01-05 Thread Issac Goldstand
On 05/01/2013 11:52, Igor Galić wrote: - Original Message - On Wednesday 02 January 2013, Eric Covener wrote: On Wed, Jan 2, 2013 at 4:02 PM, Stefan Fritsch wrote: On Wednesday 02 January 2013, Jim Jagielski wrote: For *real* improvement, wouldn't storing in socache be the optimal