On 25 Jun 2001, Jeff Trawick wrote:
> [EMAIL PROTECTED] writes:
>
> > > > Would it make more sense to have something that would be more
> > > > specific to each lock type (mutex, semaphore, read/write locks)?
> > >
> > > You tell me :)
> > >
> > > I find the whole notion of needing to tell APR whi
I attempted to propose a more elaborate form of this in one of my various
unclear messages. It may make more sense if we have two sets of function
calls (layers), one is the platform-independent stuff, and the other
is the platform-specific stuff. The former will most likely use the
latter, but bot
On Mon, Jun 25, 2001 at 07:30:51PM -0400, Jeff Trawick wrote:
> Here's an idea:
>
> Leave apr_lock_create() alone (though I think some other folks wanna
> muck with it :) ).
>
> Add apr_lock_create_np() (or some gstein-approved name) which
>
> 1) has the OS-specific details specified in enum par
[EMAIL PROTECTED] writes:
> > > Would it make more sense to have something that would be more
> > > specific to each lock type (mutex, semaphore, read/write locks)?
> >
> > You tell me :)
> >
> > I find the whole notion of needing to tell APR which mechanism to use
> > fairly klunky, and OS-specif
> > Would it make more sense to have something that would be more
> > specific to each lock type (mutex, semaphore, read/write locks)?
>
> You tell me :)
>
> I find the whole notion of needing to tell APR which mechanism to use
> fairly klunky, and OS-specific stuff like this really klunky. Given
Justin Erenkrantz <[EMAIL PROTECTED]> writes:
> On Mon, Jun 25, 2001 at 04:30:45PM -0400, Jeff Trawick wrote:
> > Did anybody want this done differently?
>
> What about Read/write locks? Those would use the same function for
> creation, but none of the values for the methods would be valid
> (ex
I think this looks great.
Do I have any support yet for a fully-separated locks API, something
to the effect of:
Inter/cross process locks handled by:
apr_lock_interprocess_*()
Intraprocess locks handled by (these could even be POSIX):
apr_lock_mutex_*()
apr_lock_cond_*()
apr_lock_rwlock_*()
..
On Mon, Jun 25, 2001 at 04:30:45PM -0400, Jeff Trawick wrote:
> Did anybody want this done differently?
What about Read/write locks? Those would use the same function for
creation, but none of the values for the methods would be valid
(except the DEFAULT).
Would it make more sense to have someth
(on Unix, at least)
Brain-dead changes are needed for win32, beos, and os2 to ensure that
the new parameter to apr_lock_create() is reasonable. I'll do it; I
just haven't done it yet.
Only the mechanism for interprocess lock can be chosen at the moment.
We can add that later if/when it is necess
> Any reason I shouldn't proceed with testing/committing? This is
> enough function to allow someone else to carry it further, and
> meanwhile we can see what build tweaks are needed on various Unix
> flavors, as this will start to compile more code into APR.
+1 from me (also useless ;)
Vict
From: "Luke Kenneth Casson Leighton" <[EMAIL PROTECTED]>
Sent: Sunday, June 24, 2001 12:05 PM
> my point of the [reducto-ad-juvenile-conclusion] comments
> above were to say, well, if you have the same names, but
> different functionality, why would you want to limit
> the [apr] functionality to
> What this means is that to block out *all* other processes and
> threads, unless we're on a system where APR_PROCESS_LOCK_IS_GLOBAL is
> defined, we need to get an interprocess lock (to block out everything
> but threads in our own process) as well as a intraprocess lock (to
> block out other thr
Aaron Bannert <[EMAIL PROTECTED]> writes:
> Even in the case where APR_PROCESS_LOCK_IS_GLOBAL is _not_ #defined,
> and the lock was created with type APR_LOCKALL, (if I'm reading this
> correctly) acquire() will do:
>
> apr_unix_lock_intra(lock)
> apr_unix_lock_inter(lock)
>
> and release() will
++1 on the readability factor (non-binding vote :)
I'm also very happy with the flexibility this will give us.
-aaron
> Note that one or two bugs were fixed in the PROC_PTHREAD_SERIALIZE
> support, but I wouldn't bet on it working... maybe we've never
> tried this with APR, or at least not in a
I still completely fail to see any place where LOCKALL would need to be
different than CROSS_PROCESS.
Even in the case where APR_PROCESS_LOCK_IS_GLOBAL is _not_ #defined,
and the lock was created with type APR_LOCKALL, (if I'm reading this
correctly) acquire() will do:
apr_unix_lock_intra(lock)
a
On Mon, Jun 25, 2001 at 08:16:06AM -0700, Ian Holsman wrote:
> There was a update to GCC from redhat over the weekend, did you
> apply that patch perhaps?
I didn't touch anything. That's what makes it odd. It didn't work, and
now it does. -- justin
On Mon, Jun 25, 2001 at 11:05:49AM -0400, Jeff Trawick wrote:
> Any reason I shouldn't proceed with testing/committing? This is
> enough function to allow someone else to carry it further, and
> meanwhile we can see what build tweaks are needed on various Unix
> flavors, as this will start to comp
Aaron Bannert <[EMAIL PROTECTED]> writes:
> > *There would have to be an intermediate routine for APR_LOCK_ALL on
> > most platforms when APR is built with thread support.
>
> I still disagree with apr_lock_*() providing both
> INTRAPROCESS and CROSS_PROCESS *in the same function calls*.
If you
On 24 Jun 2001 20:07:02 -0700, Justin Erenkrantz wrote:
> FWIW, I can't seem to reproduce the problem now. I know that I was
> getting odd things last night, but I can't seem to get it to happen
> again today. Grr. I feel silly. I could put a note in the STATUS
> file that we've seen some oddi
Note that one or two bugs were fixed in the PROC_PTHREAD_SERIALIZE
support, but I wouldn't bet on it working... maybe we've never
tried this with APR, or at least not in a long time?
1) bugs:
a) APR_PROCESS_LOCK_IS_GLOBAL and the idea of selecting the
mechanism at run-time doesn't seem
> > > Thoughts? Should we just avoid this problem and tell anyone using a
> > > default install of Mandrake that they are screwed? Or, do we just
> > > disable compiler optimizations with gcc 2.96? -- justin
> >
> > We shouldn't have to work around bugs in beta versions of the compiler.
> > If
FWIW, I can't seem to reproduce the problem now. I know that I was
getting odd things last night, but I can't seem to get it to happen
again today. Grr. I feel silly. I could put a note in the STATUS
file that we've seen some oddities with GCC 2.96. I swear I wasn't
making it up - I *was* get
On Sun, 24 Jun 2001 [EMAIL PROTECTED] wrote:
> "Your compiler is known to have bugs which stop Apache from working
> properly. Please re-configure with CFLAGS=-O2"
CFLAGS=-O0
+1
> This gets around the problem, but doesn't make us responsible for fixing
> RH and Mandrake's mistakes. If there w
23 matches
Mail list logo
