[Mono-dev] GSOC 2017 Microsoft .NET and Mono integration - Import ThreadPool from CoreRT
luhenry at microsoft.com
Mon Mar 27 17:07:44 UTC 2017
Integrating the CoreRT threadpool into Mono will be more of an experiment than a project that we envision merging by the end of GSoC into Mono. If that's find by you, then it's perfectly fine by us. Another project that would have more impact and that we are looking forward to merge would be importing System.Threading.Mutex, System.Threading.Semaphore and System.Threading.EventWaitHandle from CoreRT into Mono. Whichever project you choose is definitely up to you, and whichever you choose, it will be of great use for us.
To discuss each project in more details, importing System.Threading.ThreadPool would consist in getting https://github.com/dotnet/corert/blob/master/src/System.Private.CoreLib/src/System/Threading/ThreadPool.cs and its dependencies from CoreRT, and adapting it to the use of Mono. Some features are not supported by the CoreRT ThreadPool such as SetMinThreads, SetMaxThreads, GetMinThreads, GetMaxThreads, or other APIs, and because we cannot just drop the support for these, we need to make sure they are implemented and supported. Right now, our ThreadPool implementation is coming from ReferenceSource for the managed part and we reimplemented the native part into Mono from CoreCLR (https://github.com/mono/mono/blob/master/mono/metadata/threadpool.c and https://github.com/mono/mono/blob/master/mono/metadata/threadpool-worker-default.c).
For System.Threading.Mutex, System.Threading.Semaphore and System.Threading.EventWaitHandle, the project would consist in replacing our implementation of these classes with the one from CoreRT. Our implementation resides in https://github.com/mono/mono/blob/master/mcs/class/corlib/System.Threading/Mutex.cs, https://github.com/mono/mono/blob/master/mcs/class/referencesource/System/sys/system/threading/semaphore.cs and https://github.com/mono/mono/blob/master/mcs/class/referencesource/mscorlib/system/threading/eventwaithandle.cs respectively.
For both these projects, as well as the other integration of .NET sources into Mono, we need to ensure that we keep supporting the same platforms as before, thus fixing or extending the CoreRT implementations.
If you have any more question, I will be more than happy to answer them! :)
Thank you very much!
On 24 Mar 2017, at 12:16, dampir <aedampir at gmail.com<mailto:aedampir at gmail.com>> wrote:
I’m Alexander Efremov and I’m interested in GSOC projects of Mono.
Particulary I'm interested in "Import ThreadPool from CoreRT" (mentor
I successfully builded mono on my PC and now I think how to write a good
proposal devoted to import ThreadPool from CoreRT.
I have read 2 topics devoted to Microsoft .NET and Mono integration:
but they mainly devoted to two other integration tasks (Import
System.IO.FileStream from CoreFX,
Import Process from CoreFX).
From there I got some common understanding what is supposed to do in these
* Replace Mono's ThreadPool implementation on CoreFx one.
* Add support of some unsupported platforms to CoreFx.
* Add/edit a bunch of unit tests.
But my intention is integrate ThreadPool class from CoreFx. And in order to
write good and clear proposal I started to dig into source code connected to
Mono's ThreadPool. But I think that my knownledge about it is not enough to
create appropriate time schedule (week-by-week) in my proposal.
So my quesion is: Ludovic could you please describe in some details what
stages the integration of CoreFx ThreadPool is entail (like you describe in
for System.IO.FileStream integration)?
I'm going to use this infromation to dig in right direction.
View this message in context: http://mono.1490590.n4.nabble.com/GSOC-2017-Microsoft-NET-and-Mono-integration-Import-ThreadPool-from-CoreRT-tp4670332.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
Mono-devel-list mailing list
Mono-devel-list at lists.dot.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mono-devel-list