wangchdo commented on PR #17573: URL: https://github.com/apache/nuttx/pull/17573#issuecomment-3710852742
> > > BTW, I feel that @wangchdo has shown little respect for me: > > > > > > > > 1. I and @wangchdo each implemented our hrtimer independently, with almost no communication during the process. These implementations are completely different. In mid-December, @xiaoxiang781216 suggested that I share my design with @wangchdo . During our exchange, I pointed out his errors regarding SMP, but he refused to acknowledge them and accused me of stealing his ideas. He also asked me to submit my incomplete internal hrtimer implementation to the community. > > > > 2. Out of respect for his opinion, I submitted my design and demonstrated that it outperforms his in both functional correctness and performance. After I submitted my code implementation to the community, to my surprise, without any discussion, @anchao forcibly merged @wangchdo's functional incorrect implementation into the upstream, which made me feel very very uncomfortable. > > > > 3. Yet, @wangchdo consistently refused to replace his implementation with mine. I cannot understand why he remains so stubborn. > > > > 4. He rarely tests his own code; even pulling his PR and compiling it reveals compilation issues. He repeatedly pressured me to provide test cases for him but never offered any in return, which I find insulting. > > > > 5. I have consistently tried to reason with him, presenting performance test results, interface comparisons, and memory usage analyses. However, he refuses to acknowledge them and has not provided any convincing evidence to support his stance. > > > > > > > > I recommend that @wangchdo refer to my design and adopt hazard pointers, which are an optimal solution for memory efficiency. I have no issue with him using my design consideration (in fact, hazard pointers is memory reclamation technique proposed by others). Similar design goals inevitably lead to convergent designs, and this is entirely natural. > > > > Finally, Could you please help me review my implementation #17675? I welcome any feedback and believe that, at the very least, my implementation is superior to his in terms of functional correctness, design completeness, documentation, performance, scalability, and code reusability. =) > > > > Regarding the APIs, I have made every effort to align it with the original design. However, some aspects are inherently tied to the design and difficult to change. For example, my implementation encodes the state in `hrtimer->func`, which means restarting the timer requires passing the `func`. Besides, according to test results, this does not impact performance. > > > > > > @Fix-Point This is my last response to you: > > > > > > It is just about design choice or why we provide hrtimer module when we decide how to handle concurrency issues. What is most important before you make a decision of whether the implementation is right is that you need to consider if the behavior is what we want or what is the requirement? > > > > > > Why do we provide hrtimer, what is the correct use cases? What do we expect users to get? > > > > > > In my opinion, there is no wrong implementation, there is only implementation that meets requirements and others no. > > > > > > At the last, I don't want to talk about anything else not related to technical stuff. And I very much don't want judging anyone personally happens in our community. > > > > @wangchdo I think all change in this pr come from the discussion with @Fix-Point , so I suggest you add @Fix-Point as coauthor to acknowledge his contribution. OK, I will add @Fix-Point as coauthor to acknowledge the discussion back and forth with him. However, to be honest, I couldn't say that I enjoyed this kind of discussion, I hope next time we could discuss in a more enjoyable wway:) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
