[Mono-dev] [PATCH] System.Threading.Parallel
Miguel de Icaza
miguel at novell.com
Mon Dec 24 09:50:13 EST 2007
> While you are suddenly changing your mind here (I had asked about that
> in the first place!) while still discussing this simple&safe, self-
> contained initial implementation, I am losing time I would rather
> spend with non-mature advanced&experimental 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
> 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
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.
More information about the Mono-devel-list