[vlc-devel] [PATCH] Win32 threads: remove functions forbidden on Windows Store

Rafaël Carré funman at videolan.org
Sat Oct 19 11:52:23 CEST 2013


Le 15/10/2013 18:12, Rafaël Carré a écrit :
> ping
> Le 04/09/2013 16:56, Rafaël Carré a écrit :
>> Le 15/08/2013 14:12, Rémi Denis-Courmont a écrit :
>>> On Thu, 15 Aug 2013 13:35:52 +0200, Rafaël Carré <funman at videolan.org>
>>> wrote:
>>>> Le 15/08/2013 13:20, Rémi Denis-Courmont a écrit :
>>>>> On Thu, 15 Aug 2013 12:29:31 +0200, Rafaël Carré <funman at videolan.org>
>>>>> wrote:
>>>>>> Do not create a suspended thread so ResumeThread becomes unnecessary.
>>>>> The comment that this patch removes explains why you cannot do that.
>>>>> Also,
>>>>> I don't think Gildas would have bothered with the explicit suspension
>>> if
>>>>> it
>>>>> was not required.
>>>> The risk is the thread terminating before beginthreadex returns and that
>>>> case is handled.
>>> In a totally lame fashion that may take a whole scheduler slice to
>>> complete. I don't think that's an improvement for desktop Windows.
>> I added some debug here and this never happens when playing some h264 file.
>> In fact I wouldn't even know how to have a thread terminate immediately
>> after creation before the parent sees _beginthreadex returning.
>> Of course I can add more ifdef but that'd make the code more ugly to
>> prevent something that is quite unlikely to *ever* happen. If by misluck
>> it still happened then yeah the error (because such a quick return would
>> likely be an error) would take a few more nanoseconds before the thread
>> exits.
>> This code only runs on cleanup of detached threads and there's only 2 of
>> them: playlist preparser and fetcher. Both have no possible error case
>> and will end only after all items have been preparsed.
>> Is there still some problem that I missed?

More information about the vlc-devel mailing list