Hi all, [or all who are interested in sms :)]
The couple of weeks I've been working on a new
sms I blunty named 'trivial'. I think though that
a quick glance at the code will not enlighten
everyone, so another name is welcome.
I've attached the code for review, and will
commit as-is next week, if
Jim Jagielski <[EMAIL PROTECTED]> writes:
> One way would be to add another argument to the APR call that defines
> the lock type (enum would be best, 'natch). Whatcha think?
Note also that an APR_LOCK_ALL lock will likely need to select an
interprocess lock mechanism *and* an intraprocess lock m
> i'll do the same for mod_access_xvl when i do it, probly
> this w/e.
well, um... it was about an hour's work, on the train
*embarrassed* :)
so, here we go again:
@begin Official Notice:
Copyright and ownership of the file mod_access_xvl.c is hereby
assigned unconditionally to the Apache Soft
[ This probably doesn't belong on new-httpd except for the fact that we
are talking about the accept mutex ]
[ I also think my mailer got wacked - resend... ]
On Fri, Jun 22, 2001 at 11:15:46AM -0400, Jim Jagielski wrote:
> Jeff Trawick wrote:
> >
> > I think I'd rather see it fail.
> >
> > If
Yes, in 1.3.x is pretty trivial. It's a tiny bit more complex in
2.0, but not much. I agree that it makes sense for both versions.
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
in the following code snippet, i'm trying to get the full path for a
given file name (in argv[1]) using apr_file_get_info() and apr_stat().
in looking at apr_file_info.h, it appears that apr_finfo_t.fname should
contain the full path for the file after calling these functions, but it
does not. am
Actually; I've just written this for an in-house experiment at covalent;
by just using function pointers. See attached hack to get an idea. It is
not ready for submittal - as it does not yet have sensible default choise.
Dw
On Fri, 22 Jun 2001, Jim Jagielski wrote:
> I've been toying with the i
Sander (Temme) and I have been working on this in the last two weeks;
basically it turns out that your best mutex stategy is not just a function
of the OS, but also of the (type of) load, the # of processors and the
speed of those processor's. In particuly - if your bottle neck is a high
mutex ra
Just for some history. This was all discussed back when I first designed
the lock API. Manoj wanted separate functions, I wanted a single
function. I won, but only because I was the guy implementing it, not
because I was able to convince Manoj technically. If we want to separate
the functions
> Actually, I'd like to see function ptrs stored in apr_lock_t so that
> apr_lock_acquire() and apr_lock_release() can just call the right
> low-level routine with no checking of the lock type.*
we'd still be looking at minimum 2 function calls per each lock_acquire()
and lock_release() (and now a
Jeff Trawick wrote:
>
> I think I'd rather see it fail.
>
> If an app wants to back down to the default without informing the user
> that they picked an invalid mechanism then it is just an extra couple
> of lines.
>
> rv = apr_lock_create(aaa, APR_MUTEX_SYSVSEM, bbb);
> if (APR_STATUS_IS_ENOTIM
Well, that all makes sense to me. As does the added reasoning by Jeff,
so
-1!
Just kidding, +1, I'm behind this 100%. :-)
Ryan
On Fri, 22 Jun 2001, Jim Jagielski wrote:
> Well, that's it basically. APR chooses what's best on a per-platform
> basis, but it might not be the best ch
Aaron Bannert <[EMAIL PROTECTED]> writes:
> > If you use APR_INTRAPROCESS, you will get a light-weight thread locking
> > mechanism. What more are you looking for. In reality, for thread
> > locking, we always end up using pthreads mutex's on Unix.
>
> If by lightweight you mean (in apr_lock_ac
On 22 Jun 2001, Jeff Trawick wrote:
> I think I'd rather see it fail.
>
> If an app wants to back down to the default without informing the user
> that they picked an invalid mechanism then it is just an extra couple
> of lines.
+1
--
Jim Jagielski <[EMAIL PROTECTED]> writes:
> AcceptMutex fcntl|flock|sysv|pthread|default...
>
> As far as someone choosing a method not supported on that platform,
> then an error-no-start or error-choose-default would be the 2
> options on how Apache/APR should handle that. I think I'd pref
> If you use APR_INTRAPROCESS, you will get a light-weight thread locking
> mechanism. What more are you looking for. In reality, for thread
> locking, we always end up using pthreads mutex's on Unix.
If by lightweight you mean (in apr_lock_acquire() for example):
function overhead from apr_lo
At 3:16 PM +0100 6/22/01, Paul Hooper wrote:
>Fellow Apache Gurus
>
>Is mod_ssl shipped as standard with Apache_1.3.12 If not do you know where
>I can get a copy??
>
check out www.modssl.org and www.openssl.org
--
===
Ji
Well, that's it basically. APR chooses what's best on a per-platform
basis, but it might not be the best choice for a per-environment
basis. For example, on my Foobar box, APR may choose FCNTL, but
I've enabled/added semaphores and want to use that. Instead of having
to recompile, it would be nice
On Fri, 22 Jun 2001, Jim Jagielski wrote:
> I've been toying with the idea of making the accept mutex selection
> a runtime rather than compile-time option. This makes sense to me
> for certain applications. At present, however, APR decides the mutex
> type and Apache uses that. So we either need
>
> > - conditionals and rwlocks (these pretty much go together, and would be
> > built upon the mutex routines) -- much more heavy than simple mutexes,
> > but IMHO widely useful throughout httpd and the modules.
>
> Conditionals weren't portable when I looked at them. Basically, Windows
>
I have expressed my distaste for the "one mutex fits all" approach of APR for
quite a
while. +1
Bill
- Original Message -
From: "Jim Jagielski" <[EMAIL PROTECTED]>
To: ;
Sent: Friday, June 22, 2001 9:20 AM
Subject: Accept mutex
> I've been toying with the idea of making the accept mut
I've been toying with the idea of making the accept mutex selection
a runtime rather than compile-time option. This makes sense to me
for certain applications. At present, however, APR decides the mutex
type and Apache uses that. So we either need some way for APR to
determine all possible availabl
hi there,
well, i just wanted to write this and let you know what i'm
up to, and also cos i feel like celebrating a bit, i thought
i'd share news on what's been happening with xvl.
i started on xvl eight months ago, it's now what i think raph
levien wanted mod_virgule (running advogato.org) to be
committed... thanks!
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
hi,
following is a small patch for descriptions in apr_buckets.h
hiro hanai
Index: apr_buckets.h
===
RCS file: /pub/cvs/Apache/apr-util/include/apr_buckets.h,v
retrieving revision 1.99
diff -u -r1.99 apr_buckets.h
--- apr_buckets.h
Michael Tokarev wrote:
>
> Luke Kenneth Casson Leighton wrote:
> >
> []
> > srvsvcd's job is also to handle the dependencies for service startup.
> >
> > we could look at the linux kernel 'Calculating module dependencies'
> > code to get an algorithm to work out the startup order.
>
> Why, why, w
> I guess what I'm looking for is a lightweight thread syncronization
> API. This maybe stretching the mantra of APR ("implement what you need
> when you need it"), but I'm interested in putting some more design effort
> into the locking facilities that APR provides. Would it be of any use
> at th
On Thu, Jun 21, 2001 at 04:46:51PM -0400, Jeff Trawick wrote:
> Aaron Bannert <[EMAIL PROTECTED]> writes:
[snip]
> > I was asking about the apr implementation, nothing specific to an
> > application. Does anyone know which platforms present this kind of
> > behavior (and what are the underlying me
28 matches
Mail list logo
