[GSoC] Idea: Implement functions from Concurrency namespace
Hello, folks. I'm YongHao Hu. I participated in GSoC of Wine last year and most of the work are finished. This year I want to implement functions from Concurrency namespace[1]. As Wine had already implemented class Concurrency::critical_section[2], SpinWait and Concurrency::details::_GetConcurrency, and I had found information in Microsoft open-source project for cloud-based client-server communication in native code using a modern asynchronous C++ API design[3] which are helpful for the implementation, I think that I am able to handle this project. By now, I had made some patches as my proof of concept.[4] There are many bugs[4-8] relied on functions from Concurrency namespace, this project would fix some bugs and benefit wine's behavior on many software. By making an appropriate proposal, I think the project's work can satisfy GSoC's requirement. Thank you for reading this email. I will be grateful for any advice you can provide. [1]: https://msdn.microsoft.com/en-us/library/dd492819.aspx [2]: https://msdn.microsoft.com/en-us/library/dd492843.aspx [3]: https://github.com/Microsoft/cpprestsdk [4]: https://github.com/YongHaoWu/wine-hub/commits/Concurrency [5]: https://bugs.winehq.org/show_bug.cgi?id=37887 [6]: https://bugs.winehq.org/show_bug.cgi?id=37997 [7]: https://bugs.winehq.org/show_bug.cgi?id=39685 [8]: https://bugs.winehq.org/show_bug.cgi?id=34676 [9]: https://bugs.winehq.org/show_bug.cgi?id=37976
Hi, On 02/22/16 16:16, YongHao Hu wrote:
This year I want to implement functions from Concurrency namespace[1]. As Wine had already implemented class Concurrency::critical_section[2], SpinWait and Concurrency::details::_GetConcurrency, and I had found information in Microsoft open-source project for cloud-based client-server communication in native code using a modern asynchronous C++ API design[3] which are helpful for the implementation, I think that I am able to handle this project. I'm not sure what to think about this project. It would be nice to have this functions implemented in wine. On the other hand I'm expecting it to be quite hard.
Thanks, Piotr
Hi, On 16/2/23 下午10:33, Piotr Caban wrote:
Hi,
On 02/22/16 16:16, YongHao Hu wrote:
This year I want to implement functions from Concurrency namespace[1]. As Wine had already implemented class Concurrency::critical_section[2], SpinWait and Concurrency::details::_GetConcurrency, and I had found information in Microsoft open-source project for cloud-based client-server communication in native code using a modern asynchronous C++ API design[3] which are helpful for the implementation, I think that I am able to handle this project. I'm not sure what to think about this project. It would be nice to have this functions implemented in wine. On the other hand I'm expecting it to be quite hard.
As we can refer to some implementation of Microsoft[1], do you think it would become easier? For example, the event class[2] can refer to the pplxlinux.h[3], TaskCollection[4] can refer to pplx.h[5] and reader_writer_lock[6] can refer to pplxlinux.h[7] etc. My simple plan may like this: Add tests to critical session. Implement Class condition variable first, which can refer to BOOST and tests. Implement Class event and tests. Implement Class TaskCollection and tests. Implement Class reader_writer_lock and tests. Else: Find something that I think I can handle. Do you think such a plan would satisfy GSoC's requirement? Thank you very much. :) [1]: https://github.com/Microsoft/cpprestsdk [2]: https://msdn.microsoft.com/en-us/library/dd492846.aspx [3]: https://github.com/Microsoft/cpprestsdk/blob/master/Release/include/pplx/ppl... [4]: https://msdn.microsoft.com/en-us/library/dd470722.aspx [5]: https://github.com/Microsoft/cpprestsdk/blob/master/Release/include/pplx/ppl... [6]: https://msdn.microsoft.com/en-us/library/dd504907.aspx [7]: https://github.com/Microsoft/cpprestsdk/blob/master/Release/include/pplx/ppl...
On 02/23/16 18:12, YongHao Hu wrote:
As we can refer to some implementation of Microsoft[1], do you think it would become easier? I didn't look on it yet so I have no clue if it's going to be helpful. Probably yes.
For example, the event class[2] can refer to the pplxlinux.h[3], TaskCollection[4] can refer to pplx.h[5] and reader_writer_lock[6] can refer to pplxlinux.h[7] etc. You can get similar information from C++ standard description. You can get some basic information from there but wine's implementation will need to be binary compatible (or at least structures will need to have the same size as on windows).
My simple plan may like this: Add tests to critical session. Implement Class condition variable first, which can refer to BOOST and tests. Implement Class event and tests. Implement Class TaskCollection and tests. Implement Class reader_writer_lock and tests. Else: Find something that I think I can handle.
Do you think such a plan would satisfy GSoC's requirement? Sorry, I don't know much about Concurrency namespace yet. I just wanted to warn you that it may be harder then you expect.
Thanks, Piotr
Hi, On 16/2/24 上午1:39, Piotr Caban wrote:
On 02/23/16 18:12, YongHao Hu wrote:
As we can refer to some implementation of Microsoft[1], do you think it would become easier? I didn't look on it yet so I have no clue if it's going to be helpful. Probably yes.
For example, the event class[2] can refer to the pplxlinux.h[3], TaskCollection[4] can refer to pplx.h[5] and reader_writer_lock[6] can refer to pplxlinux.h[7] etc. You can get similar information from C++ standard description. You can get some basic information from there but wine's implementation will need to be binary compatible (or at least structures will need to have the same size as on windows).
I want to mention that even the structures, class and functions have implementation in the open-source project.[1,2,3] For example, in [1], as far as I am concerned, we can implement Class event in Wine base on this. Of course, we also need to be binary compatible. class event_impl { private: cpprest_synchronization::mutex _lock; cpprest_synchronization::condition_variable _condition; bool _signaled; public: static const unsigned int timeout_infinite = 0xFFFFFFFF; event_impl() : _signaled(false) { } void set() { cpprest_synchronization::lock_guard<cpprest_synchronization::mutex> lock(_lock); _signaled = true; _condition.notify_all(); } void reset() { cpprest_synchronization::lock_guard<cpprest_synchronization::mutex> lock(_lock); _signaled = false; } unsigned int wait(unsigned int timeout) { cpprest_synchronization::unique_lock<cpprest_synchronization::mutex> lock(_lock); if (timeout == event_impl::timeout_infinite) { _condition.wait(lock, [this]() -> bool { return _signaled; }); return 0; } else { cpprest_synchronization::chrono::milliseconds period(timeout); auto status = _condition.wait_for(lock, period, [this]() -> bool { return _signaled; }); _ASSERTE(status == _signaled); // Return 0 if the wait completed as a result of signaling the event. Otherwise, return timeout_infinite // Note: this must be consistent with the behavior of the Windows version, which is based on WaitForSingleObjectEx return status ? 0: event_impl::timeout_infinite; } };
My simple plan may like this: Add tests to critical session. Implement Class condition variable first, which can refer to BOOST and tests. Implement Class event and tests. Implement Class TaskCollection and tests. Implement Class reader_writer_lock and tests. Else: Find something that I think I can handle.
Do you think such a plan would satisfy GSoC's requirement? Sorry, I don't know much about Concurrency namespace yet. I just wanted to warn you that it may be harder then you expect.
Thank you for your attention. I will consider it deeply. [1]: https://github.com/Microsoft/cpprestsdk/blob/master/Release/include/pplx/ppl... [2]: https://github.com/Microsoft/cpprestsdk/blob/master/Release/include/pplx/ppl... [3]: https://github.com/Microsoft/cpprestsdk/blob/master/Release/include/pplx/ppl...
It's perhaps worth mentioning that the Apache License (v2) is not compatible with the (L)GPL2.
Hi, thank you for your mention. Though Apache License(v2) is not compatible with the (L)GPL2, we can read the code instead of copying them, right? On 16/2/26 上午2:50, Henri Verbeet wrote:
It's perhaps worth mentioning that the Apache License (v2) is not compatible with the (L)GPL2. Thanks.
Regards.
participants (3)
-
Henri Verbeet -
Piotr Caban -
YongHao Hu