Re: [Mono-dev] [PATCH] System.Threading.Parallel
Hello, Thanks for the comments. I do not see such an example in my diff: I have not modified corlib yet, just svn-copied and modified the relevant build files from another assembly and added my own, see below. ECMA_PARALLEL_SUPPORT is not being defined anywhere, should I better use #if 0 to make it more obvious? Yes, #if 0 is more obvious. This patch seems independent of Microsoft's new parallel library, and the extensible way of implementing it I suggested on another thread would likely enable us to share backends between both libraries. That part is not implemented yet, I'd like to have a working base revision first, which this patch is intended as. Would be great if we could get something in before Christmas, then I can work on the next gen between the years before I start my number crunching in January. If you are going to share anything between this library and ParallelExtensions then the code should go to olive repository as we maintain CTP or experimental libraries there. Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] System.Threading.Parallel
Hello Miguel, Unfortunately I don't have regular Internet access right now. Am 24.12.2007 um 15:50 schrieb Miguel de Icaza: Am not sure that I we have known where this code would go, as I stated to you in an email on December 11th: If you have an implementation, we would not have a problem bundling it. The question is on which assembly it goes. There is some extra background in the email regarding this particular assembly. Yes, and I read it. That was your response to my asking specifically about mcs/. Your saying you'd not have a problem bundling it seemed to confirm the location mcs/ as you didn't reject or propose another location. So without further responses, I put my code into mcs/. Regarding the above question of an assembly, I replied on Dec 12 that according to the standard this were System.Threading.Parallel.dll and corlib. I got no further response on that indicating you actually meant repository folder/directory/module rather than assembly. If you did/do actually mean to create a new non-standardized assembly then there is little point in exactly duplicating the ECMA interface, I could then go with static (wrapper) methods for some operations rather than creating instance objects, and from my view such a custom assembly shouldn't go into either of mcs or olive then. A separate repository is usually a good idea to let libraries mature, as I mentioned on my emails, the ECMA System.Threading.Parallel was submitted by Intel, but as far as we know, no implementation was ever tested on real applications, so it avoided the entire refining cycle. But I'm in no position to change the ECMA standard! So there will be no such refining cycle now either, wherever we put the code - only the users' choice of whether to use that API or not. As a matter of policy, we have had libraries developed externally for months (or even years) before they went into mcs. System.Core and Cecil are two examples. But also, we are trying hard to reduce the number of assemblies that we ship (there are numerous posts on this subject elsewhere), but the basic problem is that mcs has become too large and bugs in a an area require releasing the entire Mono to fix those problems. And today we suffer from various early mistakes when plenty of libraries made it into mcs, We now regard shipping inside mcs as a liability, and have even initiated the planning to split out all the Microsoft- specific libraries into a separate module and keep mcs with the bare minimum needed. In fact, even libraries as important as Mono.ZeroConf that have been under development for more than a year are not part of mcs today. I did not notice such posts on Mono-dev, but as you might guess this move in general has my support, it would greatly speed up the build process from SVN. It is only unfortunate that this patch has blocked my working copy and further work on this for two weeks just to be told clearly now that you're not interested in including it in mcs/ as-is. I had read that you'd rather have classes implemented throwing NotImplementedExceptions than not having them implemented at all, so providing a fully implemented missing assembly seemed like a nice and easy way to contribute back to the Mono community... turns out not to be so straightforward. The downside of moving STP elsewhere is two-fold: * Providing such a minimalistic implementation inside mcs/ would have got the assembly/API into the next release, deploying it and enabling people to start developing against it. * And the ECMA/System.* nature of this assembly should enable us to subsequently replace the initial implementation without users having to redirect any strongly versioned references via .config file for each application. We can offer you the hosting space as well (similar to what we do with Cocoa#) and an svn account, and when code depends on it we could decide where it goes into mcs or olive. Mono.ZeroConf, Cocoa-sharp and all the others are not ECMA assemblies and thus much easier to build. I do have an account, so if likely we have to duplicate parts of Mono's build system then some place in SVN might still be reasonable for tracking changes, whether a personal branch or somewhere in trunk. For now I have imported the non-olive code into a new local repository; if you decide on where you'd like to have what, I could look into exporting/importing something in early January. Andreas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] System.Threading.Parallel
Hello, This patch seems independent of Microsoft's new parallel library, and the extensible way of implementing it I suggested on another thread would likely enable us to share backends between both libraries. That part is not implemented yet, I'd like to have a working base revision first, which this patch is intended as. Would be great if we could get something in before Christmas, then I can work on the next gen between the years before I start my number crunching in January. If you are going to share anything between this library and ParallelExtensions then the code should go to olive repository as we maintain CTP or experimental libraries there. Not sure I got you right: Attached is a draft patch against olive for the Parallel Extensions (don't have a Microsoft .NET 3.5 environment to test or even browse its documentation in, there is none on the Web except two MSDN Magazine articles). How is it related to 3.5 ? To share code between olive/ and mcs/, the shared code will have to go into mcs/, otherwise it would not be usable for STP there, as olive/ is optional. The alternative would be to move STP outside mcs/ but that would limit its deployment and usefulness (and I wouldn't know how to build it correctly :). My opinion is that both components are optional and should go to olive repository until they mature enough. Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] System.Threading.Parallel
Hello, Am 24.12.2007 um 13:13 schrieb Marek Safar: Attached is a draft patch against olive for the Parallel Extensions (don't have a Microsoft .NET 3.5 environment to test or even browse its documentation in, there is none on the Web except two MSDN Magazine articles). How is it related to 3.5 ? The article I puzzled these bits and pieces together from says PE support 3.5+ only. As you can see in the patch, it relies on System.Core.dll, which to my knowledge was not in 2.0. To share code between olive/ and mcs/, the shared code will have to go into mcs/, otherwise it would not be usable for STP there, as olive/ is optional. The alternative would be to move STP outside mcs/ but that would limit its deployment and usefulness (and I wouldn't know how to build it correctly :). My opinion is that both components are optional and should go to olive repository until they mature enough. Sure they are optional, just like all the ADO.NET providers in mcs/ which cannot even be disabled during bootstrap. STP on the other hand (unlike PE) is part of the ECMA standard, and, thank you very much, I have spent a lot of time and effort making this initial implementation mature enough. Nobody has spotted anything in my code that was not mature. While you are suddenly changing your mind here (I had asked about that in the first place!) while still discussing this simplesafe, self- contained initial implementation, I am losing time I would rather spend with non-mature advancedexperimental implementations thereof and with my applications using it. So if you don't want it, please don't waste my time, I'll have to version it in another repository to continue my work, just like Cocoa-sharq. Sad thing really. Merry Christmas anyway. Andreas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] System.Threading.Parallel
Hello Andreas, While you are suddenly changing your mind here (I had asked about that in the first place!) while still discussing this simplesafe, self- contained initial implementation, I am losing time I would rather spend with non-mature advancedexperimental implementations thereof and with my applications using it. Am not sure that I we have known where this code would go, as I stated to you in an email on December 11th: If you have an implementation, we would not have a problem bundling it. The question is on which assembly it goes. There is some extra background in the email regarding this particular assembly. So if you don't want it, please don't waste my time, I'll have to version it in another repository to continue my work, just like Cocoa-sharq. Sad thing really. A separate repository is usually a good idea to let libraries mature, as I mentioned on my emails, the ECMA System.Threading.Parallel was submitted by Intel, but as far as we know, no implementation was ever tested on real applications, so it avoided the entire refining cycle. As a matter of policy, we have had libraries developed externally for months (or even years) before they went into mcs. System.Core and Cecil are two examples. But also, we are trying hard to reduce the number of assemblies that we ship (there are numerous posts on this subject elsewhere), but the basic problem is that mcs has become too large and bugs in a an area require releasing the entire Mono to fix those problems. And today we suffer from various early mistakes when plenty of libraries made it into mcs, We now regard shipping inside mcs as a liability, and have even initiated the planning to split out all the Microsoft-specific libraries into a separate module and keep mcs with the bare minimum needed. In fact, even libraries as important as Mono.ZeroConf that have been under development for more than a year are not part of mcs today. We can offer you the hosting space as well (similar to what we do with Cocoa#) and an svn account, and when code depends on it we could decide where it goes into mcs or olive. Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] System.Threading.Parallel
So given that the two do not conflict I see three options: - add System.Threading.Parallel.ParallelEnvironment to corlib and conditionally depend on its presence (similar to now), or This is not likely going to happen, as code compiled on Mono would not run on .NET. We have avoided modifying the public API exposed for the sake of portability. This needs to be a standalone assembly so that software can be used on Linux and Unix. As for helper methods, that am not too concerned about, the number of processors at this point is something that Mono does not do much with, so the whole policy can be included in this new assembly. Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] System.Threading.Parallel
Am 23.12.2007 um 11:44 schrieb Andreas Färber: Hello, Am 22.12.2007 um 23:49 schrieb Marek Safar: ECMA_PARALLEL_SUPPORT is not being defined anywhere, should I better use #if 0 to make it more obvious? Yes, #if 0 is more obvious. Actually this breaks compilation: System.Threading.Parallel/ParallelFor.cs(51,1): error CS1517: Invalid preprocessor directive System.Threading.Parallel/ParallelFor.cs(51,1): error CS1025: Single- line comment or end-of-line expected System.Threading.Parallel/ParallelForEach.cs(53,1): error CS1517: Invalid preprocessor directive System.Threading.Parallel/ParallelForEach.cs(53,1): error CS1025: Single-line comment or end-of-line expected System.Threading.Parallel/ParallelWhile.cs(53,1): error CS1517: Invalid preprocessor directive System.Threading.Parallel/ParallelWhile.cs(53,1): error CS1025: Single- line comment or end-of-line expected Compilation failed: 6 error(s), 0 warnings Any alternatives? (In C this works...) Andreas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] System.Threading.Parallel
Hello, #if false should work. Thanks, Jonathan On Dec 23, 2007 11:01 AM, Andreas Färber [EMAIL PROTECTED] wrote: Am 23.12.2007 um 11:44 schrieb Andreas Färber: Hello, Am 22.12.2007 um 23:49 schrieb Marek Safar: ECMA_PARALLEL_SUPPORT is not being defined anywhere, should I better use #if 0 to make it more obvious? Yes, #if 0 is more obvious. Actually this breaks compilation: System.Threading.Parallel/ParallelFor.cs(51,1): error CS1517: Invalid preprocessor directive System.Threading.Parallel/ParallelFor.cs(51,1): error CS1025: Single- line comment or end-of-line expected System.Threading.Parallel/ParallelForEach.cs(53,1): error CS1517: Invalid preprocessor directive System.Threading.Parallel/ParallelForEach.cs(53,1): error CS1025: Single-line comment or end-of-line expected System.Threading.Parallel/ParallelWhile.cs(53,1): error CS1517: Invalid preprocessor directive System.Threading.Parallel/ParallelWhile.cs(53,1): error CS1025: Single- line comment or end-of-line expected Compilation failed: 6 error(s), 0 warnings Any alternatives? (In C this works...) Andreas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] System.Threading.Parallel
Hey, Am 23.12.2007 um 17:06 schrieb Jonathan Chambers: #if false should work. Thanks, should have read the C# spec *before* posting ... just found that nice feature! Updated patch attached. Andreas System.Threading.Parallel-2007-12-23b.diff Description: Binary data On Dec 23, 2007 11:01 AM, Andreas Färber [EMAIL PROTECTED] wrote: Am 23.12.2007 um 11:44 schrieb Andreas Färber: Hello, Am 22.12.2007 um 23:49 schrieb Marek Safar: ECMA_PARALLEL_SUPPORT is not being defined anywhere, should I better use #if 0 to make it more obvious? Yes, #if 0 is more obvious. Actually this breaks compilation: System.Threading.Parallel/ParallelFor.cs(51,1): error CS1517: Invalid preprocessor directive System.Threading.Parallel/ParallelFor.cs(51,1): error CS1025: Single- line comment or end-of-line expected System.Threading.Parallel/ParallelForEach.cs(53,1): error CS1517: Invalid preprocessor directive System.Threading.Parallel/ParallelForEach.cs(53,1): error CS1025: Single-line comment or end-of-line expected System.Threading.Parallel/ParallelWhile.cs(53,1): error CS1517: Invalid preprocessor directive System.Threading.Parallel/ParallelWhile.cs(53,1): error CS1025: Single- line comment or end-of-line expected Compilation failed: 6 error(s), 0 warnings Any alternatives? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] System.Threading.Parallel
Am 21.12.2007 um 15:23 schrieb Marek Safar: I would not add this to corlib as it may cause problems later when MS introduces better Parallel library support. To completely support the Parallel Library, in addition the ParallelEnvironment class would need to be implemented inside corlib. But with Microsoft not having supported it, relying on its presence would keep users from deploying this assembly to .NET. The proposed implementation therefore uses conditional sections where ParallelEnvironment should theoretically be used. It seems Microsoft is using one or multiple instances of System.Concurrency.TaskManager to control the number of concurrent threads. ParallelEnvironment.MaxThreads roughly corresponds to the global TaskManager's .MaxConcurrentThreads. Adding that class to corlib might require a new icall for ParallelEnvironment,RecommendedMaxThreads (to discover the number of processors/cores) I found that System.Environment.ProcessorCount already returns the number of processors or cores. Therefore no icall would be required, the scaling could be done in managed code. So given that the two do not conflict I see three options: - add System.Threading.Parallel.ParallelEnvironment to corlib and conditionally depend on its presence (similar to now), or - add a public Mono.Threading.Parallel.ParallelEnvironment to our System.Threading.Parallel.dll and (conditionally) use this one instead, or - add a (System|Mono).Threading.Parallel.ParallelEnvironment in a separate, Mono-specific assembly Without the class in corlib, any source/IL code conformant to the standard would break. With the class correctly in corlib, code using it cannot be deployed to non-conforming Microsoft .NET. With the class in a Mono-specific assembly, code using this class is not standard-conformant. With a Mono-specific class in SPT, code using this class is no longer standard-conformant. With a Mono-specific class in a Mono-specific assembly, runtime behavior is undefined for any other SPT implementation. I'd favor having it in corlib for completeness and providing a custom frontend in a Mono assembly; that could then check for Parallel support via Reflection and set/get the value either there or locally. Mono's SPT could then rely on its deployable companion assembly as an Adapter to work on both Mono and any other runtime. Andreas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] System.Threading.Parallel
Am 22.12.2007 um 23:49 schrieb Marek Safar: This patch seems independent of Microsoft's new parallel library, and the extensible way of implementing it I suggested on another thread would likely enable us to share backends between both libraries. That part is not implemented yet, I'd like to have a working base revision first, which this patch is intended as. Would be great if we could get something in before Christmas, then I can work on the next gen between the years before I start my number crunching in January. If you are going to share anything between this library and ParallelExtensions then the code should go to olive repository as we maintain CTP or experimental libraries there. Not sure I got you right: Attached is a draft patch against olive for the Parallel Extensions (don't have a Microsoft .NET 3.5 environment to test or even browse its documentation in, there is none on the Web except two MSDN Magazine articles). System.Concurrency-2007-12-23.dll Description: application/msdownload To share code between olive/ and mcs/, the shared code will have to go into mcs/, otherwise it would not be usable for STP there, as olive/ is optional. The alternative would be to move STP outside mcs/ but that would limit its deployment and usefulness (and I wouldn't know how to build it correctly :). Andreas___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] System.Threading.Parallel
Am 22.12.2007 um 03:11 schrieb Miguel de Icaza: My suggestion is that this library should stay out of mscorlib, allowing this code to be reused by those that might have an interest for it on Windows (so this library would also be usable by folks on the Windows platforms if they chose to do that). Sure, it does so and, as previously mentioned to you, I intend to keep it that way. So is the patch okay then, or do you require any specific changes before committing it? Andreas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] System.Threading.Parallel
Hi Andreas, It seems to me your diff is not complete as some files rely on working copy of files which don't exist. I would not add this to corlib as it may cause problems later when MS introduces better Parallel library support. Marek Attached is a patch adding the System.Threading.Parallel assembly, an optional part of the ECMA-335 standard (Annex G). The initial implementation is single-threaded, as permitted by the standard. All my test cases pass. Please review. Am I correct to use the ecma.pub key for this ECMA-only assembly? And am I seeing correctly that the ECMA docs do not document protected methods? I used internal protected to be on the safe side for now. There are some comments inline, documenting where I needed to interpret the standard. For instance, the standard says an exception should be rethrown in EndRun, which I am doing now, but this of course hides the original source of the exception, so maybe we should not rethrow it but throw some new exception with it as InnerException? To completely support the Parallel Library, in addition the ParallelEnvironment class would need to be implemented inside corlib. But with Microsoft not having supported it, relying on its presence would keep users from deploying this assembly to .NET. The proposed implementation therefore uses conditional sections where ParallelEnvironment should theoretically be used. Adding that class to corlib might require a new icall for ParallelEnvironment,RecommendedMaxThreads (to discover the number of processors/cores), and if so I assume the corlib version would need to be incremented? Thanks, Andreas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] System.Threading.Parallel
Hi Marek, Thanks for the comments. I do not see such an example in my diff: I have not modified corlib yet, just svn-copied and modified the relevant build files from another assembly and added my own, see below. ECMA_PARALLEL_SUPPORT is not being defined anywhere, should I better use #if 0 to make it more obvious? svn status w/o irrelevant parts: M class/Makefile ? class/System.Threading.Parallel/TestResult-NET_2_0.log ? class/System.Threading.Parallel/ System.Threading.Parallel_test_NET_2_0.dll.mdb A class/System.Threading.Parallel A class/System.Threading.Parallel/Assembly A + class/System.Threading.Parallel/Assembly/AssemblyInfo.cs A class/System.Threading.Parallel/Assembly/ChangeLog A + class/System.Threading.Parallel/ System.Threading.Parallel.dll.sources A class/System.Threading.Parallel/Test A class/System.Threading.Parallel/Test/System.Threading.Parallel A class/System.Threading.Parallel/Test/System.Threading.Parallel/ ChangeLog A class/System.Threading.Parallel/Test/System.Threading.Parallel/ ParallelForTest.cs A class/System.Threading.Parallel/Test/System.Threading.Parallel/ ParallelForEachTest.cs A class/System.Threading.Parallel/Test/System.Threading.Parallel/ ParallelWhileTest.cs A class/System.Threading.Parallel/System.Threading.Parallel A class/System.Threading.Parallel/System.Threading.Parallel/ ParallelFor.cs A class/System.Threading.Parallel/System.Threading.Parallel/ ChangeLog A class/System.Threading.Parallel/System.Threading.Parallel/ ParallelForEach.cs A class/System.Threading.Parallel/System.Threading.Parallel/ ParallelWhile.cs A class/System.Threading.Parallel/System.Threading.Parallel/ ParallelLoop.cs A class/System.Threading.Parallel/ChangeLog A + class/System.Threading.Parallel/Makefile A class/System.Threading.Parallel/ System.Threading.Parallel_test.dll.sources M class/ChangeLog This patch seems independent of Microsoft's new parallel library, and the extensible way of implementing it I suggested on another thread would likely enable us to share backends between both libraries. That part is not implemented yet, I'd like to have a working base revision first, which this patch is intended as. Would be great if we could get something in before Christmas, then I can work on the next gen between the years before I start my number crunching in January. Concerning corlib, Dennis posted a list of namespaces affected by Microsoft's new library, and ParallelEnvironment would not seem to conflict with that. More than that I do not know. Personally, I'd rather stick with the published ECMA standard and a superior Mono implementation than with some evolving Microsoft CTP potentially leading to IPR questions at some point. Virtually nobody uses their Compute Cluster Edition anyway. Andreas Am 21.12.2007 um 15:23 schrieb Marek Safar: Hi Andreas, It seems to me your diff is not complete as some files rely on working copy of files which don't exist. I would not add this to corlib as it may cause problems later when MS introduces better Parallel library support. Marek Attached is a patch adding the System.Threading.Parallel assembly, an optional part of the ECMA-335 standard (Annex G). The initial implementation is single-threaded, as permitted by the standard. All my test cases pass. Please review. Am I correct to use the ecma.pub key for this ECMA-only assembly? And am I seeing correctly that the ECMA docs do not document protected methods? I used internal protected to be on the safe side for now. There are some comments inline, documenting where I needed to interpret the standard. For instance, the standard says an exception should be rethrown in EndRun, which I am doing now, but this of course hides the original source of the exception, so maybe we should not rethrow it but throw some new exception with it as InnerException? To completely support the Parallel Library, in addition the ParallelEnvironment class would need to be implemented inside corlib. But with Microsoft not having supported it, relying on its presence would keep users from deploying this assembly to .NET. The proposed implementation therefore uses conditional sections where ParallelEnvironment should theoretically be used. Adding that class to corlib might require a new icall for ParallelEnvironment,RecommendedMaxThreads (to discover the number of processors/cores), and if so I assume the corlib version would need to be incremented? Thanks, Andreas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list
Re: [Mono-dev] [PATCH] System.Threading.Parallel
Hello, Concerning corlib, Dennis posted a list of namespaces affected by Microsoft's new library, and ParallelEnvironment would not seem to conflict with that. More than that I do not know. Personally, I'd rather stick with the published ECMA standard and a superior Mono implementation than with some evolving Microsoft CTP potentially leading to IPR questions at some point. Virtually nobody uses their Compute Cluster Edition anyway. Well, the problem with System.Threading.Parallel is that it has never been used in practice as far as I know. This was an API designed by Intel and submitted to ECMA, but as far as am aware, it did not go through the regular process of API usability testing or got any use beyond its definition. The CTP process (or any other process) in which APIs are implemented and then refined based on actual usage patterns did not benefit this library. My suggestion is that this library should stay out of mscorlib, allowing this code to be reused by those that might have an interest for it on Windows (so this library would also be usable by folks on the Windows platforms if they chose to do that). miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] System.Threading.Parallel
Am 13.12.2007 um 23:34 schrieb Andreas Färber: Attached is a patch adding the System.Threading.Parallel assembly, an optional part of the ECMA-335 standard (Annex G). The initial implementation is single-threaded, as permitted by the standard. All my test cases pass. Please review. Am I correct to use the ecma.pub key for this ECMA-only assembly? And am I seeing correctly that the ECMA docs do not document protected methods? I used internal protected to be on the safe side for now. There are some comments inline, documenting where I needed to interpret the standard. For instance, the standard says an exception should be rethrown in EndRun, which I am doing now, but this of course hides the original source of the exception, so maybe we should not rethrow it but throw some new exception with it as InnerException? No comments for one week? Can I go ahead and commit the initial version then? Andreas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
