[Mono-dev] [PATCH] System.Threading.Parallel
andreas.faerber at web.de
Thu Dec 27 11:10:26 EST 2007
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
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
> ship (there are numerous posts on this subject elsewhere), but the
> 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
> made it into mcs, We now regard shipping inside mcs as a liability,
> have even initiated the planning to split out all the Microsoft-
> libraries into a separate module and keep "mcs" with the bare minimum
> 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
> 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
> 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.
More information about the Mono-devel-list