you might as well memcpy() if you're going to strlen() first. it's less
complex inline code.
-dean
On Tue, 19 Jun 2001, Doug MacEachern wrote:
> the current apr_strcat does strlen() twice for each argument, this patch
> makes it happen just once. it would also be handy to have an apr_pstrcatn
On Tue, Jul 17, 2001 at 04:49:04PM -0700, dean gaudet wrote:
> > Please allow me to use pseudocode:
> >
> > void * worker_function(void * opaque_application_data) {
> >
> >apr_pool_t *thread_pool;
> >
> >create_child_pool(&thread_pool, global_root_pool);
>
> now you've got mutexes in globa
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. A
[snip]
> > that would be registered in the "parent" thread's pool -- and would only
> > be invoked by the "parent" thread.
> >
> > pools let you do this, you don't need the mutexes for it, you just have to
> > be explicit about parallelism. (combine that with a root pool per thread
> > and then w
On Tue, Jul 17, 2001 at 06:28:37PM -0500, William A. Rowe, Jr. wrote:
> Yes, yes, yes. Can we please split the concept of a heirarchial parent (the
> 'creator' thread's or process pool, in this case) from the allocation parent
> (the actual give me memory for my pool from ... here!) Then we have
you might want to disassemble the functions in gdb (or using objdump) to
make sure that gcc emits a single division instruction for the "x / 10",
"x % 10" expressions -- i forget the cases where it can and can't do this.
the low level div instruction is a two result opcode, quotient and
remainder.
From: "dean gaudet" <[EMAIL PROTECTED]>
Sent: Tuesday, July 17, 2001 6:15 PM
> if you assume that you want some form of notification, but you want to
> leave it unspecified because you're not sure what each apr thread will be
> used for, then you can make a somewhat generic "kill off other thread
:)
all is not lost.
if you assume that you want some form of notification, but you want to
leave it unspecified because you're not sure what each apr thread will be
used for, then you can make a somewhat generic "kill off other threads"
cleanup.
so for example, when an httpd thread is created it
On Tue, 17 Jul 2001, Justin Erenkrantz wrote:
> And, from what I can tell, Dean Gaudet has mentioned this morning that
> he is willing to veto async notification. Dean, would that include
> cancellation of threads? I have a suspicion it might. Dean has
> commit access on httpd as well, so if yo
On Tue, 17 Jul 2001, Luke Kenneth Casson Leighton wrote:
> therefore, i conclude that the dce/rpc codebase has successfully
> implemented thread cancellation in their POSIX/Draft4 thread
> library.
yes cancellation is in the spec. i've never denied that. the problem is
libraries and code over
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
+++ include/
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:
> B
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
w
"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 t
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 fro
On Tue, Jul 17, 2001 at 10:59:03AM -0700, Brian Pane wrote:
> the unsynchronized approach can crash due to a race condition.) Thus my
> argument is that this scenario (forking from a threaded MPM and then trying
> to clean up the other threads' resources in the child process) isn't a
> valid use c
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
invo
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 "base" on top of
On Tue, Jul 17, 2001 at 12:13:08PM -0500, William A. Rowe, Jr. wrote:
> Because, otherwise, all resources (files, sockets, locks, etc) are not closed
> when
> another thread forks.
>
> There is a difference between a clean thread exit and cleaning up after a
> thread.
> We can't do a clean threa
> 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 h
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
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:
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 "base" on top of it. Shouldn't it b
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 could be halfway through registering a new resource (e.g.,
file descrip
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
> 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
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. That isn't
> workable.
I disagree with this. I gave my big long monologue on this
> 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
William A. Rowe, Jr. wrote:
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 sho
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 creat
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. Act
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, 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,
> > it will make the dynamic locking a lot ea
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
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,
+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 leavi
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
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
any comments on this patch?
I'd really like it in there so I can submit a bigger patch which would
convert the 'notes' table to a hash table.
Ian Holsman wrote:
This is the first part of allow notes 'tables' to become hash tables.
the patch adds a function to 'merge' two hash tables together, a
Hi,
After being bitten by make_exports and friends a few times
I decided to look into fixing it.
The results are attached.
I think this will be a usefull replacement for the
build_exports/make_exports in httpd.
Sander
make_exports.awk
Description: Binary data
> 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 persistent
> connection across multiple remote function calls.
>
> this impli
hiya,
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 persistent
connection across multiple remote function calls.
this implies that
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 effectively
> kill all threads. What am I missing?
how does a thread kill another thread?
-dean
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
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 s
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
=
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
47 matches
Mail list logo
