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
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 you
:)
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
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. if
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 an
[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 we can remove
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,
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 global_root_pool.
From: Aaron Bannert [EMAIL PROTECTED]
Sent: Tuesday, July 17, 2001 6:41 PM
[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
I totally agree, but only as a solution in httpd.
no, everywhere.
I also believe that we should provide this [application-specific
requirement]
outside of the basic thread support in APR.
Please allow me to use pseudocode:
void * worker_function(void *
[...]
Are you saying you want the thread function to have access to both a
scope pool as well as an allocator pool, in case they are different?
I've officially graduated to the rbb (insert a decent name here) club :-)
Thank you, yes, scope pool defines teardowns such as cleanups,
while
On Tue, 17 Jul 2001, William A. Rowe, Jr. wrote:
We agree. APR_INHERIT is the 'option', APR_NON_INHERIT is a zero (usual
case) value.
my complaint is that you're modifying all the handle creation APIs with
another parameter...
-dean
On Tue, Jul 17, 2001 at 08:32:47PM -0500, William A. Rowe, Jr. wrote:
Then, I'm +1 on _not_ passing this as an argument to the creation fn, rather
assuming
that the inherit flag is _not_ set, and force the user to call
apr_socket_inherit_set
or apr_file_inherit_set.
Does this work for
dean gaudet wrote:
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
+1 from me too (although i don't know that i necessarily have a vote in
APR :)
-dean
On Tue, 17 Jul 2001, Justin Erenkrantz wrote:
On Tue, Jul 17, 2001 at 08:32:47PM -0500, William A. Rowe, Jr. wrote:
Then, I'm +1 on _not_ passing this as an argument to the creation fn,
rather assuming
On Tue, Jul 17, 2001 at 08:33:09PM -0700, dean gaudet wrote:
[snip]
p.s. maybe this example will help highlight why apr_lock_t is far too
generic and there should be a more lightweight thread only mutex that
doesn't require lots of extra memory allocation?
Oh don't get me started on that
On Tue, Jul 17, 2001 at 10:12:35AM -0700, Aaron Bannert wrote:
- Optionally creating a child-pool for each thread. This provides us two
things in my mind:
1) Allowing the application to choose an SMS for this thread-pool (which
could very well be a special SMS created just for this
On Wed, Jul 18, 2001 at 01:52:54PM +0200, Luke Kenneth Casson Leighton wrote:
On Tue, Jul 17, 2001 at 05:49:08PM -0700, Justin Erenkrantz wrote:
Comments? Would this make anyone happy? =)
yes, funnily enough.
you intend this to be part of the sms 'utility' API, yes?
a bit like
++1
Ryan
On Wed, 18 Jul 2001, Sander Striker wrote:
Hi,
I've written a new make_exports.awk script which I posted to the list
earlier. Attached is a newer version which seems to handle everything
ok now.
To move to the new make_exports the following steps are required:
- copy
Yup. That's the catch. It'd probably need to be a bit more
sophisticated than what I've posted OR make the apr_sms_reset a bit more
robust (i.e. handle SMSes that have already been cleaned up). I'm
leaning towards making the apr_sms_reset more robust. -- justin
yeah, well it seems to me
-1. Please post patches in-line, because it makes it MUCH easier to reply
to them and make useful comments. Also, posting one patch at a time
would have made this patch easier to follow, and it would have
allowed me to commit the pieces that I like without having to go in
and modify the patch
yeah, well it seems to me that this would be a really smart
thing to do _anyway_.
throw an assert if someone tries to register the same
'object' twice, not just a child-sms.
is that possible?
Possible, yes :)
if you have a file object, how can you check it's not the same?
by
From: Justin Erenkrantz [EMAIL PROTECTED]
Sent: Wednesday, July 18, 2001 10:01 AM
On Wed, Jul 18, 2001 at 01:52:54PM +0200, Luke Kenneth Casson Leighton wrote:
also, what happens if the child sms is *already part of the parent*?
can you guarantee that the registration and destruction of
On Wed, Jul 18, 2001 at 05:30:17PM +0200, Sander Striker wrote:
can you guarantee that the registration and destruction of the
sms, via cleanup, will not stuff the parent by effectively
destroying the child sms twice?
Yup. That's the catch. It'd probably need to be a bit more
IMNSHO, this is wrong for two reasons. #1, if the app has access to the
apr_thread_t, then they also have access to the pool.
For the app to get access to the apr_thread_t, it must pass it through
in it's own opaque data pointer. This is of course totally unobvious to
the application
[ Dropping tomcat-dev and adding [EMAIL PROTECTED] ]
On Wed, Jul 18, 2001 at 05:10:43PM +0100, Pier P. Fumagalli wrote:
Justin Erenkrantz at [EMAIL PROTECTED] wrote:
On Wed, Jul 18, 2001 at 04:43:57PM +0100, Pier P. Fumagalli wrote:
I have an old pre-sms version of APR I'm using, and it
William A. Rowe, Jr. at [EMAIL PROTECTED] wrote:
From: Justin Erenkrantz [EMAIL PROTECTED]
Sent: Wednesday, July 18, 2001 11:23 AM
[ Dropping tomcat-dev and adding [EMAIL PROTECTED] ]
On Wed, Jul 18, 2001 at 05:10:43PM +0100, Pier P. Fumagalli wrote:
Justin Erenkrantz at [EMAIL
Given the current code for SMS, it is hard to separate the 'scope' vs.
'allocation' parent. Roy and I discussed yesterday about playing some
trickery with having the thread-specific SMS be parented by the std SMS
(i.e. malloc et al) and the per-process pool (i.e. passed into
On Wed, Jul 18, 2001 at 11:59:28PM +0200, Sander Striker wrote:
Look at the code again. Specifically in apr_sms_destroy. You'll see
there that the child sms is removed from the child list like so:
if ((*sms-ref = sms-sibling) != NULL)
sms-sibling-ref = sms-ref;
Which is an inexpensive
29 matches
Mail list logo
