[Mono-dev] [PATCH] System.Threading.Parallel

[Andreas Färber]

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