You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@apr.apache.org by tr...@apache.org on 2004/03/01 22:05:44 UTC
cvs commit: apr/threadproc/win32 thread.c
trawick 2004/03/01 13:05:44
Modified: . CHANGES
include apr_thread_proc.h
include/arch/os2 apr_arch_threadproc.h
include/arch/win32 apr_arch_threadproc.h
threadproc/beos thread.c
threadproc/netware thread.c
threadproc/os2 thread.c
threadproc/unix thread.c
threadproc/win32 thread.c
Log:
Add apr_threadattr_stacksize_set() for overriding the default
stack size for threads created by apr_thread_create().
This is currently a not-implemented stub for BeOS.
Revision Changes Path
1.452 +4 -0 apr/CHANGES
Index: CHANGES
===================================================================
RCS file: /home/cvs/apr/CHANGES,v
retrieving revision 1.451
retrieving revision 1.452
diff -u -r1.451 -r1.452
--- CHANGES 13 Feb 2004 09:38:23 -0000 1.451
+++ CHANGES 1 Mar 2004 21:05:44 -0000 1.452
@@ -7,6 +7,10 @@
Changes with APR 1.0
+ *) Add apr_threadattr_stacksize_set() for overriding the default
+ stack size for threads created by apr_thread_create().
+ [Jeff Trawick]
+
*) The whole codebase was relicensed and is now available under
the Apache License, Version 2.0 (http://www.apache.org/licenses).
[Apache Software Foundation]
1.102 +8 -0 apr/include/apr_thread_proc.h
Index: apr_thread_proc.h
===================================================================
RCS file: /home/cvs/apr/include/apr_thread_proc.h,v
retrieving revision 1.101
retrieving revision 1.102
diff -u -r1.101 -r1.102
--- apr_thread_proc.h 13 Feb 2004 09:38:28 -0000 1.101
+++ apr_thread_proc.h 1 Mar 2004 21:05:44 -0000 1.102
@@ -216,6 +216,14 @@
APR_DECLARE(apr_status_t) apr_threadattr_detach_get(apr_threadattr_t *attr);
/**
+ * Set the stack size of newly created threads.
+ * @param attr The threadattr to affect
+ * @param on The stack size in bytes
+ */
+APR_DECLARE(apr_status_t) apr_threadattr_stacksize_set(apr_threadattr_t *attr,
+ apr_size_t stacksize);
+
+/**
* Create a new thread of execution
* @param new_thread The newly created thread handle.
* @param attr The threadattr to use to determine how to create the thread
1.3 +1 -0 apr/include/arch/os2/apr_arch_threadproc.h
Index: apr_arch_threadproc.h
===================================================================
RCS file: /home/cvs/apr/include/arch/os2/apr_arch_threadproc.h,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- apr_arch_threadproc.h 13 Feb 2004 09:38:30 -0000 1.2
+++ apr_arch_threadproc.h 1 Mar 2004 21:05:44 -0000 1.3
@@ -27,6 +27,7 @@
struct apr_threadattr_t {
apr_pool_t *pool;
unsigned long attr;
+ apr_size_t stacksize;
};
struct apr_thread_t {
1.3 +1 -0 apr/include/arch/win32/apr_arch_threadproc.h
Index: apr_arch_threadproc.h
===================================================================
RCS file: /home/cvs/apr/include/arch/win32/apr_arch_threadproc.h,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- apr_arch_threadproc.h 13 Feb 2004 09:38:31 -0000 1.2
+++ apr_arch_threadproc.h 1 Mar 2004 21:05:44 -0000 1.3
@@ -35,6 +35,7 @@
struct apr_threadattr_t {
apr_pool_t *pool;
apr_int32_t detach;
+ apr_size_t stacksize;
};
struct apr_threadkey_t {
1.38 +6 -0 apr/threadproc/beos/thread.c
Index: thread.c
===================================================================
RCS file: /home/cvs/apr/threadproc/beos/thread.c,v
retrieving revision 1.37
retrieving revision 1.38
diff -u -r1.37 -r1.38
--- thread.c 13 Feb 2004 09:38:36 -0000 1.37
+++ thread.c 1 Mar 2004 21:05:44 -0000 1.38
@@ -49,6 +49,12 @@
return APR_NOTDETACH;
}
+APR_DECLARE(apr_status_t) apr_threadattr_stacksize_set(apr_threadattr_t *attr,
+ apr_size_t stacksize)
+{
+ return APR_ENOTIMPL;
+}
+
static void *dummy_worker(void *opaque)
{
apr_thread_t *thd = (apr_thread_t*)opaque;
1.16 +7 -0 apr/threadproc/netware/thread.c
Index: thread.c
===================================================================
RCS file: /home/cvs/apr/threadproc/netware/thread.c,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- thread.c 13 Feb 2004 09:38:37 -0000 1.15
+++ thread.c 1 Mar 2004 21:05:44 -0000 1.16
@@ -50,6 +50,13 @@
return APR_NOTDETACH;
}
+APR_DECLARE(apr_status_t) apr_threadattr_stacksize_set(apr_threadattr_t *attr,
+ apr_size_t stacksize)
+{
+ attr->stack_size = stacksize;
+ return APR_SUCCESS;
+}
+
static void *dummy_worker(void *opaque)
{
apr_thread_t *thd = (apr_thread_t *)opaque;
1.39 +10 -2 apr/threadproc/os2/thread.c
Index: thread.c
===================================================================
RCS file: /home/cvs/apr/threadproc/os2/thread.c,v
retrieving revision 1.38
retrieving revision 1.39
diff -u -r1.38 -r1.39
--- thread.c 13 Feb 2004 09:38:37 -0000 1.38
+++ thread.c 1 Mar 2004 21:05:44 -0000 1.39
@@ -33,6 +33,7 @@
(*new)->pool = pool;
(*new)->attr = 0;
+ (*new)->stacksize = 0;
return APR_SUCCESS;
}
@@ -51,7 +52,12 @@
return (attr->attr & APR_THREADATTR_DETACHED) ? APR_DETACH : APR_NOTDETACH;
}
-
+APR_DECLARE(apr_status_t) apr_threadattr_stacksize_set(apr_threadattr_t *attr,
+ apr_size_t stacksize)
+{
+ attr->stacksize = stacksize;
+ return APR_SUCCESS;
+}
static void apr_thread_begin(void *arg)
{
@@ -94,7 +100,9 @@
}
thread->tid = _beginthread(apr_thread_begin, NULL,
- APR_THREAD_STACKSIZE, thread);
+ thread->attr->stacksize > 0 ?
+ thread->attr->stacksize : APR_THREAD_STACKSIZE,
+ thread);
if (thread->tid < 0) {
return errno;
1.57 +16 -0 apr/threadproc/unix/thread.c
Index: thread.c
===================================================================
RCS file: /home/cvs/apr/threadproc/unix/thread.c,v
retrieving revision 1.56
retrieving revision 1.57
diff -u -r1.56 -r1.57
--- thread.c 13 Feb 2004 09:38:37 -0000 1.56
+++ thread.c 1 Mar 2004 21:05:44 -0000 1.57
@@ -78,6 +78,22 @@
return APR_NOTDETACH;
}
+APR_DECLARE(apr_status_t) apr_threadattr_stacksize_set(apr_threadattr_t *attr,
+ apr_size_t stacksize)
+{
+ int stat;
+
+ stat = pthread_attr_setstacksize(&attr->attr, stacksize);
+ if (stat == 0) {
+ return APR_SUCCESS;
+ }
+#ifdef PTHREAD_SETS_ERRNO
+ stat = errno;
+#endif
+
+ return stat;
+}
+
static void *dummy_worker(void *opaque)
{
apr_thread_t *thread = (apr_thread_t*)opaque;
1.56 +14 -2 apr/threadproc/win32/thread.c
Index: thread.c
===================================================================
RCS file: /home/cvs/apr/threadproc/win32/thread.c,v
retrieving revision 1.55
retrieving revision 1.56
diff -u -r1.55 -r1.56
--- thread.c 13 Feb 2004 09:38:38 -0000 1.55
+++ thread.c 1 Mar 2004 21:05:44 -0000 1.56
@@ -38,6 +38,9 @@
}
(*new)->pool = pool;
+ (*new)->detach = 0;
+ (*new)->stacksize = 0;
+
return APR_SUCCESS;
}
@@ -55,6 +58,13 @@
return APR_NOTDETACH;
}
+APR_DECLARE(apr_status_t) apr_threadattr_stacksize_set(apr_threadattr_t *attr,
+ apr_size_t stacksize)
+{
+ attr->stacksize = stacksize;
+ return APR_SUCCESS;
+}
+
static void *dummy_worker(void *opaque)
{
apr_thread_t *thd = (apr_thread_t *)opaque;
@@ -89,13 +99,15 @@
* same size as the calling thread.
*/
#ifndef _WIN32_WCE
- if (((*new)->td = (HANDLE)_beginthreadex(NULL, 0,
+ if (((*new)->td = (HANDLE)_beginthreadex(NULL,
+ attr && attr->stacksize > 0 ? attr->stacksize : 0,
(unsigned int (APR_THREAD_FUNC *)(void *))dummy_worker,
(*new), 0, &temp)) == 0) {
return APR_FROM_OS_ERROR(_doserrno);
}
#else
- if (((*new)->td = CreateThread(NULL, 0,
+ if (((*new)->td = CreateThread(NULL,
+ attr && attr->stacksize > 0 ? attr->stacksize : 0,
(unsigned int (APR_THREAD_FUNC *)(void *))dummy_worker,
(*new), 0, &temp)) == 0) {
return apr_get_os_error();
Re: cvs commit: apr/threadproc/win32 thread.c
Posted by Jeff Trawick <tr...@attglobal.net>.
William A. Rowe, Jr. wrote:
> At 03:05 PM 3/1/2004, trawick@apache.org wrote:
>
>>trawick 2004/03/01 13:05:44
>>
>> Add apr_threadattr_stacksize_set() for overriding the default
>> stack size for threads created by apr_thread_create().
>
>
> Tell us - does this really scale?
If you mean "is this a perfect abstract model" then of course the answer is no.
It is not even an abstract model at all, as you point out below. It is
simply a knob, required in order for some apps to be apr apps because of the
way thread stacks are usually handled (a fixed amount set at thread creation time).
> Can an arbitrary value, e.g. 128k,
> have any relationship between 32bit and 64bit platforms, or those
> with significantly different register pus/pop lists?
wink
> It seems this might make the platform less transparent, contrary
> to apr's purpose. It seems like passing some value such as stack
> words (32/64 bit quantities) and or stack call depth hints might be
> more consistent to use. Comments/ideas?
This seems pretty difficult since as far as the stack is concerned my poor
little app/Apache module/whatever is really my piece of code + apr apr-util
libc Berkeley db FOO-client-library etc. etc. etc. What could I expect the
providers of all those other libraries to give me? The characteristics of the
call trees that I actually use in the library? Worst-case requirements based
on overall library capabilities? What if the requirements are different for
different platforms? I just don't see being able to determine abstract
characteristics except for relatively small pieces of code. For the whole app?
Too hard, even if all the library providers try to help. In the end? Bump
it up to XXX and see if that is enough to fix the overflow. Or trim it down to
YYY and see if that frees up some unnecessary heap storage.
Re: cvs commit: apr/threadproc/win32 thread.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 03:05 PM 3/1/2004, trawick@apache.org wrote:
>trawick 2004/03/01 13:05:44
>
> Add apr_threadattr_stacksize_set() for overriding the default
> stack size for threads created by apr_thread_create().
Tell us - does this really scale? Can an arbitrary value, e.g. 128k,
have any relationship between 32bit and 64bit platforms, or those
with significantly different register pus/pop lists?
It seems this might make the platform less transparent, contrary
to apr's purpose. It seems like passing some value such as stack
words (32/64 bit quantities) and or stack call depth hints might be
more consistent to use. Comments/ideas?
Bill
Re: cvs commit: apr/threadproc/win32 thread.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 08:01 PM 3/1/2004, Jeff Trawick wrote:
>William A. Rowe, Jr. wrote:
>>At 04:14 PM 3/1/2004, Jeff Trawick wrote:
>>>trawick@apache.org wrote:
>>>>
>>>> (*new)->pool = pool;
>>>>+ (*new)->detach = 0;
>>>
>>>btw, detach was previously uninitialized storage; I dunno what the real-world repurcussions of that are
>>
>>if it was opaque, is alloc'ed and assigned consistently - then the only side
>>effect are the odds that some cases were previously misinterpreted as detached. This would have caused ugly side effects, so your patch is fine.
>
>I was just curious about how harmful in practical terms the occasional CloseHandle() on the thread handle would be...
I missed the gist of your Q - 18 mos ago I walked through all the cases when
the proc handles were used - time to repeat for proc and thread handles.
Bill
Re: cvs commit: apr/threadproc/win32 thread.c
Posted by Jeff Trawick <tr...@attglobal.net>.
William A. Rowe, Jr. wrote:
> At 04:14 PM 3/1/2004, Jeff Trawick wrote:
>
>>trawick@apache.org wrote:
>>
>>>trawick 2004/03/01 13:05:44
>>> threadproc/win32 thread.c
>>
>>> 1.56 +14 -2 apr/threadproc/win32/thread.c
>>>
>>> Index: thread.c
>>> ===================================================================
>>> RCS file: /home/cvs/apr/threadproc/win32/thread.c,v
>>> retrieving revision 1.55
>>> retrieving revision 1.56
>>> diff -u -r1.55 -r1.56
>>> --- thread.c 13 Feb 2004 09:38:38 -0000 1.55
>>> +++ thread.c 1 Mar 2004 21:05:44 -0000 1.56
>>> @@ -38,6 +38,9 @@
>>> }
>>>
>>> (*new)->pool = pool;
>>> + (*new)->detach = 0;
>>
>>btw, detach was previously uninitialized storage; I dunno what the real-world repurcussions of that are
>
>
> if it was opaque, is alloc'ed and assigned consistently - then the only side
> effect are the odds that some cases were previously misinterpreted as
> detached. This would have caused ugly side effects, so your patch is fine.
I was just curious about how harmful in practical terms the occasional
CloseHandle() on the thread handle would be...
Re: cvs commit: apr/threadproc/win32 thread.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 04:14 PM 3/1/2004, Jeff Trawick wrote:
>trawick@apache.org wrote:
>>trawick 2004/03/01 13:05:44
>> threadproc/win32 thread.c
>
>> 1.56 +14 -2 apr/threadproc/win32/thread.c
>>
>> Index: thread.c
>> ===================================================================
>> RCS file: /home/cvs/apr/threadproc/win32/thread.c,v
>> retrieving revision 1.55
>> retrieving revision 1.56
>> diff -u -r1.55 -r1.56
>> --- thread.c 13 Feb 2004 09:38:38 -0000 1.55
>> +++ thread.c 1 Mar 2004 21:05:44 -0000 1.56
>> @@ -38,6 +38,9 @@
>> }
>>
>> (*new)->pool = pool;
>> + (*new)->detach = 0;
>
>btw, detach was previously uninitialized storage; I dunno what the real-world repurcussions of that are
if it was opaque, is alloc'ed and assigned consistently - then the only side
effect are the odds that some cases were previously misinterpreted as
detached. This would have caused ugly side effects, so your patch is fine.
Re: cvs commit: apr/threadproc/win32 thread.c
Posted by Jeff Trawick <tr...@attglobal.net>.
trawick@apache.org wrote:
> trawick 2004/03/01 13:05:44
>
> threadproc/win32 thread.c
> 1.56 +14 -2 apr/threadproc/win32/thread.c
>
> Index: thread.c
> ===================================================================
> RCS file: /home/cvs/apr/threadproc/win32/thread.c,v
> retrieving revision 1.55
> retrieving revision 1.56
> diff -u -r1.55 -r1.56
> --- thread.c 13 Feb 2004 09:38:38 -0000 1.55
> +++ thread.c 1 Mar 2004 21:05:44 -0000 1.56
> @@ -38,6 +38,9 @@
> }
>
> (*new)->pool = pool;
> + (*new)->detach = 0;
btw, detach was previously uninitialized storage; I dunno what the real-world
repurcussions of that are
Re: cvs commit: apr/threadproc/win32 thread.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 03:05 PM 3/1/2004, trawick@apache.org wrote:
>trawick 2004/03/01 13:05:44
>
> Add apr_threadattr_stacksize_set() for overriding the default
> stack size for threads created by apr_thread_create().
Tell us - does this really scale? Can an arbitrary value, e.g. 128k,
have any relationship between 32bit and 64bit platforms, or those
with significantly different register pus/pop lists?
It seems this might make the platform less transparent, contrary
to apr's purpose. It seems like passing some value such as stack
words (32/64 bit quantities) and or stack call depth hints might be
more consistent to use. Comments/ideas?
Bill