The CVS server at Apache.org has been moved to cvs.apache.org. If you
have any trouble checking things out, please make sure that you are
checking out from cvs.apache.org.
Ryan
_
Ryan Bloom
Yep...
That fixed it.
Thanks
[EMAIL PROTECTED] wrote:
rbb 01/07/16 16:43:22
Modified:network_io/unix sockets.c
Log:
Fix a compile break in sockets.c
Revision ChangesPath
1.82 +1 -1 apr/network_io/unix/sockets.c
Index: sockets.c
On Sat, 14 Jul 2001, Aaron Bannert wrote:
On Sat, Jul 14, 2001 at 12:10:30PM -0700, [EMAIL PROTECTED] wrote:
On Sat, 14 Jul 2001, Sander Striker wrote:
The way I see it, each process has a single pool instance as the parent
for all the threads. Resetting or destroying that pool should
On Sun, 15 Jul 2001, Sander Striker wrote:
Why are we so desperate in opting out the child-pool creation?
I don't really have problems with a child pool for each thread. Actually,
it will make the dynamic locking a lot easier to implement if it stays.
all threads MUST have their own private
Sorry, I forgot to mention how to run it, although
it is very simple.
From httpd-2.0 do:
$ awk -f make_exports.awk include/*.h srclib/*/include/*.h exports.c
That's all.
Sander [who is very late and typing this while leaving...]
Hi,
After being bitten by make_exports and friends a few
On Tue, Jul 17, 2001 at 06:49:20AM -0700, [EMAIL PROTECTED] wrote:
well, in amongst all this about threads etc. i just wanted
to let you know that i happened across the context_app
example in the dce 1.22 codebase. it is an example
client and server that maintains a context - a
+1
Ryan
On Tue, 17 Jul 2001, Sander Striker wrote:
Sorry, I forgot to mention how to run it, although
it is very simple.
From httpd-2.0 do:
$ awk -f make_exports.awk include/*.h srclib/*/include/*.h exports.c
That's all.
Sander [who is very late and typing this while leaving...]
Normally this would be done (in POSIX) with pthread_cancel(), passing it
the pthread_t from the other thread.
Unfortunately, this is not a part of APR because many of the current OS
implementations of this mechanism will leak resources (aparently in the
kernel), and that is bad.
-aaron
On Tue,
On Tue, Jul 17, 2001 at 03:26:29PM +0200, Luke Kenneth Casson Leighton wrote:
therefore, i conclude that the dce/rpc codebase has successfully
implemented thread cancellation in their POSIX/Draft4 thread
library.
additionally, the context app, being threaded, has to have
locking on the
Uh...you knew that already, didn't you... duh...
jeez now i'm the smartass ;)
-aaron
On Tue, Jul 17, 2001 at 08:43:18AM -0700, Aaron Bannert wrote:
Normally this would be done (in POSIX) with pthread_cancel(), passing it
the pthread_t from the other thread.
Unfortunately, this is not a
On Tue, 17 Jul 2001, Aaron Bannert wrote:
On Tue, Jul 17, 2001 at 01:29:47AM -0700, dean gaudet wrote:
On Sun, 15 Jul 2001, Sander Striker wrote:
Why are we so desperate in opting out the child-pool creation?
I don't really have problems with a child pool for each thread. Actually,
From: [EMAIL PROTECTED]
Sent: Tuesday, July 17, 2001 11:13 AM
I believe that the problem is that the threaded code is creating the
pool, and not advertising it to the thread itself. This is an easy thing
to fix. I do not agree that every APR app that uses threads should have
to create
I'm not sure that the alternative is workable, either.
At the time of the fork, when the child process gets a snapshot of
the parent's memory, it's possible that some thread other than the one
invoking fork could be halfway through registering a new resource (e.g.,
file descriptor) in its
We have hit an impass in my mind. Dean and I are saying that having each
thread have it's own pool is a requirement. Not just for httpd, but for
anything using pools. Dean, if I am mis-interpreting you, then I am
sorry, and please correct me.
Aaron, you disagree. you want each app to
From: Justin Erenkrantz [EMAIL PROTECTED]
Sent: Tuesday, July 17, 2001 12:00 PM
On Tue, Jul 17, 2001 at 11:26:55AM -0500, William A. Rowe, Jr. wrote:
But _unless_ they remain rooted to the top level pool, in
apr_process_create
they become orphaned, and their cleanups are never executed.
On Tue, Jul 17, 2001 at 10:17:01AM -0700, Brian Pane wrote:
Aaron Bannert wrote:
I'm not sure that the alternative is workable, either.
At the time of the fork, when the child process gets a snapshot of
the parent's memory, it's possible that some thread other than the one
invoking fork
On Sun, 8 Jul 2001, Mo DeJong wrote:
Since my last patch re upgrading autoconf and libtool was not received
with open arms, I decided to take the decidedly less fun route and
get things working with both autoconf 2.13 and 2.50 as well as
libtool 1.3 and 1.4. Here is a patch that implements
Humm, I don't seem to be having much luck getting this autoconf
and libtool upgrade patch accepted. Is there a specific reason
this patch was not added? It does not require anything new
Yes, the patch makes a whole bunch of changes to the MM configure, which
only Ralf wants to maintain and he
Aaron Bannert wrote:
On Tue, Jul 17, 2001 at 10:17:01AM -0700, Brian Pane wrote:
Aaron Bannert wrote:
I'm not sure that the alternative is workable, either.
At the time of the fork, when the child process gets a snapshot of
the parent's memory, it's possible that some thread other than the one
Ian Holsman wrote:
Brian Pane wrote:
Ian Holsman wrote:
any comments on this patch?
I just read through it, and I have one major and one minor
issue:
1. Is it just my imagination, or is the overlay logic backwards?
It looks like you're making a copy of overlay and then
writing elements from
Roy T. Fielding [EMAIL PROTECTED] writes:
Humm, I don't seem to be having much luck getting this autoconf
and libtool upgrade patch accepted. Is there a specific reason
this patch was not added? It does not require anything new
Yes, the patch makes a whole bunch of changes to the MM
Brian Pane wrote:
Ian Holsman wrote:
Brian Pane wrote:
Ian Holsman wrote:
any comments on this patch?
I just read through it, and I have one major and one minor
issue:
1. Is it just my imagination, or is the overlay logic backwards?
It looks like you're making a copy of overlay and then
FYI...
-- Forwarded Message
From: Brian P Millett [EMAIL PROTECTED]
Organization: Enterprise Consulting Group
Date: Tue, 17 Jul 2001 17:16:32 -0500
To: tomcat-dev@jakarta.apache.org
Cc: Pier Fumagalli [EMAIL PROTECTED]
Subject: Re: latest cvs checkout test
Pier P. Fumagalli wrote:
Brian P
Ok..
the revised patch.(and test prog)
Index: include/apr_hash.h
===
RCS file: /home/cvspublic/apr/include/apr_hash.h,v
retrieving revision 1.25
diff -u -b -r1.25 apr_hash.h
--- include/apr_hash.h 2001/05/16 05:30:51 1.25
+++
24 matches
Mail list logo
