You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Jeff Trawick <tr...@attglobal.net> on 2004/03/01 23:14:57 UTC
Re: cvs commit: apr/threadproc/win32 thread.c
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 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.