Quantcast

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

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

dampir
This post was updated on .
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 described 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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Jo Shields via Mono-devel-list
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.cshttps://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 <[hidden email]> 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
[hidden email]
http://lists.dot.net/mailman/listinfo/mono-devel-list


_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.dot.net/mailman/listinfo/mono-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

dampir
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 <[hidden email]>:
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.cshttps://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 <[hidden email]> 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
[hidden email]
http://lists.dot.net/mailman/listinfo/mono-devel-list



_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.dot.net/mailman/listinfo/mono-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Jo Shields via Mono-devel-list
Hi Alexander,

I left a comment on your proposal, and please submit a proposal on the GSoC website too at https://summerofcode.withgoogle.com/

Thank you very much!
Ludovic

On 29 Mar 2017, at 09:39, Александр Ефремов <[hidden email]> wrote:

Hello Ludovic,

I'm Alexander Efremov, I wrote to you an email about importing of ThreadPool from CoreRT.


I decided to choose importing synchronization primitives () but I have some questions about this task.

1. I created proposal and share it on Google Docs: Proposal. It is a draft of course and I have some difficulties with time schedule. Now it is quite scratchy time schedule. I will be appriciated if you add some comments and suggestions for it and help to make it in more fine grained.

2. Question about WaitHandle class: in order to import these three primitives (EventWaitHandle, Mutex, Semaphore) we have to import WaitHandle class firstly. It is quite huge class and I prefer to start import this in community bounding period. Can I do so? It is like some preliminary work that require as much time as possible.

3. There are two inheritors of EventWaitHandle - ManualResetEvent and AutoResetEvent. Should we import them too as part of GSoC?

For any trouble with google doc sharing, I attached offline version of my proposal.

Best regards,
Alexander Efremov.


<Proposal_GSoC_2017_Alexander_Efremov_Sync_Primitives.docx>


_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.dot.net/mailman/listinfo/mono-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Jo Shields via Mono-devel-list
And to answer your questions (sorry I missed it in the first email):

2. Importing any of the dependencies of EventWaitHandle, Mutex and Semaphore should be done as part of the GSoC, so I think you shouldn't start working on it beforehand.

3. If you are done with importing EventWaitHandle, Mutex and Semaphore, then we would definitely appreciate if you import ManualResetEvent and AutoResetEvent, but I don't think we should set it as part of the goal.

Thank you!
Ludovic

On 29 Mar 2017, at 11:52, Ludovic Henry via Mono-devel-list <[hidden email]> wrote:

Hi Alexander,

I left a comment on your proposal, and please submit a proposal on the GSoC website too at https://summerofcode.withgoogle.com/

Thank you very much!
Ludovic

On 29 Mar 2017, at 09:39, Александр Ефремов <[hidden email]> wrote:

Hello Ludovic,

I'm Alexander Efremov, I wrote to you an email about importing of ThreadPool from CoreRT.


I decided to choose importing synchronization primitives () but I have some questions about this task.

1. I created proposal and share it on Google Docs: Proposal. It is a draft of course and I have some difficulties with time schedule. Now it is quite scratchy time schedule. I will be appriciated if you add some comments and suggestions for it and help to make it in more fine grained.

2. Question about WaitHandle class: in order to import these three primitives (EventWaitHandle, Mutex, Semaphore) we have to import WaitHandle class firstly. It is quite huge class and I prefer to start import this in community bounding period. Can I do so? It is like some preliminary work that require as much time as possible.

3. There are two inheritors of EventWaitHandle - ManualResetEvent and AutoResetEvent. Should we import them too as part of GSoC?

For any trouble with google doc sharing, I attached offline version of my proposal.

Best regards,
Alexander Efremov.


<Proposal_GSoC_2017_Alexander_Efremov_Sync_Primitives.docx>

_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.dot.net/mailman/listinfo/mono-devel-list


_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.dot.net/mailman/listinfo/mono-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Jo Shields via Mono-devel-list

Your proposal looks good to me.

 

From: Александр Ефремов <[hidden email]>
Date: Wednesday, 29 March 2017 at 13:48
To: Ludovic Henry <[hidden email]>
Subject: Re: [Mono-dev] GSOC 2017 Microsoft .NET and Mono integration - Import ThreadPool from CoreRT

 

Ludovic,

 

I reworked the proposal and share the draft on GSoC site.

 

Thank you and best regards,

Alexander Efremov.

 

2017-03-29 23:31 GMT+07:00 Александр Ефремов <[hidden email]>:

Thank you for these clarifications, I'm going to rework time schedule and upload proposal on GSoC site.

 

Best regrads,

Alexander Efremov.

 

2017-03-29 22:55 GMT+07:00 Ludovic Henry <[hidden email]>:

And to answer your questions (sorry I missed it in the first email):

 

2. Importing any of the dependencies of EventWaitHandle, Mutex and Semaphore should be done as part of the GSoC, so I think you shouldn't start working on it beforehand.

 

3. If you are done with importing EventWaitHandle, Mutex and Semaphore, then we would definitely appreciate if you import ManualResetEvent and AutoResetEvent, but I don't think we should set it as part of the goal.

 

Thank you!

Ludovic

 

On 29 Mar 2017, at 11:52, Ludovic Henry via Mono-devel-list <[hidden email]> wrote:

 

Hi Alexander,

 

I left a comment on your proposal, and please submit a proposal on the GSoC website too at https://summerofcode.withgoogle.com/

 

Thank you very much!

Ludovic

 

On 29 Mar 2017, at 09:39, Александр Ефремов <[hidden email]> wrote:

 

Hello Ludovic,

 

I'm Alexander Efremov, I wrote to you an email about importing of ThreadPool from CoreRT.

 

 

I decided to choose importing synchronization primitives () but I have some questions about this task.

 

1. I created proposal and share it on Google Docs: Proposal. It is a draft of course and I have some difficulties with time schedule. Now it is quite scratchy time schedule. I will be appriciated if you add some comments and suggestions for it and help to make it in more fine grained.

 

2. Question about WaitHandle class: in order to import these three primitives (EventWaitHandle, Mutex, Semaphore) we have to import WaitHandle class firstly. It is quite huge class and I prefer to start import this in community bounding period. Can I do so? It is like some preliminary work that require as much time as possible.

 

3. There are two inheritors of EventWaitHandle - ManualResetEvent and AutoResetEvent. Should we import them too as part of GSoC?

 

For any trouble with google doc sharing, I attached offline version of my proposal.

 

Best regards,

Alexander Efremov.

 

 

<Proposal_GSoC_2017_Alexander_Efremov_Sync_Primitives.docx>

 

_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.dot.net/mailman/listinfo/mono-devel-list

 

 

 


_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.dot.net/mailman/listinfo/mono-devel-list
Loading...