[vlc-devel] [PATCH] coreaudio: fix deadlock on interruption
remi at remlab.net
Wed Dec 13 09:01:10 CET 2017
Le 13 décembre 2017 09:27:02 GMT+02:00, Steve Lhomme <robux4 at gmail.com> a écrit :
>On Tue, Dec 12, 2017 at 9:50 PM, Rémi Denis-Courmont <remi at remlab.net>
>> Le tiistaina 12. joulukuuta 2017, 18.50.22 EET Carola Nitz a écrit :
>>> So correct me if I’m wrong, but we both want to spent less time on
>>> here and do it right correct ? To avoid another “obviously wrong
>>> (wasting my time in creating it and yours in reviewing it) would it
>>> possible that you could just tell me how to do it instead ?
>> Probably for the past ten years in a row, I have been writing the
>> technical content (cumulating documentation, commit messages and code
>> reviews). I have neither motivation nor time to write even more -
>> now that I noticed the propensity to ignore or skip more detailed
>> and documentations more.
>> The VLC specifics involved in this specific patch series are actually
>> documented. Unlike many other VLC subsystems I wrote the effing
>> I should not have had to re-explain those details again. The rest is
>> language. As for the circular buffer issue, it is not only a generic
>> but I have *already* highlighted it on this very mailing list... so
>While I think it's fair not to have the same conversation to solve the
>same problems over and over, I don't think it's fair to refer to a 9
>years old thread and assume everyone should have read it. Was that
>even VLC 1.0 at the time ? The code certainly has changed and improved
>in the meantime as well as tools available from the language and OS.
>> a great example of how explaining things ends up a waste of my time.
>> Besides, the goal of the review is to sort out what can/should be
>> to solve the problems of the reviewee. Plus, as far as I am aware,
>usage of my
>> time is discretionary.
>> Those are my views and I am well aware that the last sentence clashes
>> mainstream open-source guidelines for code review or more generally
>> with new or less experienced community members.
>> Those guidelines are solely focused on attracting more people. They
>> address the issues of reviewer burn-out and how time spent in review
>> training is not spent on design, development and debugging. It is
>> that the open-source community adopts more pragmatic guidelines,
>> finite availability of qualified human resources (time, motivation)
>> into serious consideration.
>> tl;dr: I will only give explanations when I see fit, and I
>> see fit.
>> vlc-devel mailing list
>> To unsubscribe or modify your subscription options:
>vlc-devel mailing list
>To unsubscribe or modify your subscription options:
This is not something from a nine years old thread (and the thread was not nine years old when the circular buffer was merged). This is a principle of threaded programming in C. This is older than VLC itself (e.g. POSIX 1997).
The thread was written so that people don't copy bad examples in the VLC code at the time. Those bad examples have been removed, and threads are now specified in ISO C (2011). So nowadays, you are expected to be aware if you are involved with threads in VLC code.
In my opinion, this is totally fair. There was nobody to explain these things to me; I documented myself. And it is easier to document yourself now than it was then.
I am not your CS teacher (and in all likelihood, s/he was paid, while I am not). In fact, I am not a teacher at all.
More information about the vlc-devel