+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
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
+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
> 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
- 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?
> > >
>
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
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
- 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
> > 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
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
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
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
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.
+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
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
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.
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
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
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,
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
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
21 matches
Mail list logo