Re: GSOC 2017 Microsoft .NET and Mono integration - Import ThreadPool from CoreRT

Александр Ефремов <[email protected]>
Newsgroups gmane.comp.gnome.mono.devel
Message-ID <CAC6a80SXHpj8vWgXs+RR+Ygtvi3sNKiDRdd40gRvyz=p-GuU2w@mail.gmail.com>
Ludovic, thank you for this information, I decided to choose importing
synchronization primitives, because it is less experimental than ThreadPool
importing. I'll send some questions about this task on your private email.

Thank you!

2017-03-28 0:07 GMT+07:00 Ludovic Henry <[email protected]>:

> Hi Alexander,
>
> 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!
> Ludovic
>
>
>
> On 24 Mar 2017, at 12:16, dampir <[email protected]> wrote:
>
> Hi,
>
> I’m Alexander Efremov and I’m interested in GSOC projects of Mono.
>
> Particulary I'm interested in "Import ThreadPool from CoreRT" (mentor
> Ludovic Henry).
>
> 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:
> http://lists.dot.net/pipermail/mono-devel-list/2017-March/044200.html
> http://mono.1490590.n4.nabble.com/Microsoft-NET-and-Mono-
> integration-GSOC-2017-td4670288.html
>
> 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
> tasks, exactly:
> * 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
> http://mono.1490590.n4.nabble.com/Re-Interest-in-GSoC-NET-
> and-Mono-integration-td4670260.html
> for System.IO.FileStream integration)?
>
> I'm going to use this infromation to dig in right direction.
>
> Thank you.
>
>
>
> --
> 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
> [email protected]
> http://lists.dot.net/mailman/listinfo/mono-devel-list
>
>
>

_______________________________________________
Mono-devel-list mailing list
[email protected]
http://lists.dot.net/mailman/listinfo/mono-devel-list
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.