[Mono-dev] [PATCH] ParallelFx initial code drop

[Jérémie Laval]

>
> - The patch has to be integrated into mscorlib first, some parts have to be
> rewritten because there is no LINQ in mscorlib


Fixed.

- Missing or not implemented functionality should be marked with MonoTODO
> attribute for future references.
>
- In some cases it should be better to use existing type containers like
> Tuple instead of creating new ones.
>

Ok.

The patch, as is, can't be reviewed as it's too big to have someone make
> sense of it. And even after comments, it will be hard to review how those
> were applied.
>
> So here is my suggestion, can we start with System.Collections.Concurrent?
> Send a patch per new public type and we can start reviewing it.
>
>
Alright.

--
Jérémie Laval
jeremie.laval at gmail.com
http://garuma.wordpress.com


2009/7/27 Rodrigo Kumpera <kumpera at gmail.com>

>
>
> 2009/7/27 Jérémie Laval <jeremie.laval at gmail.com>
>
>> Hello folks,
>>
>> ParallelFx[0] is a library designed to help programmers write more easily
>> parallel and concurrent code on .NET platform. As part of Summer of Code
>> (this year and last year), I coded a free reimplementation of this library
>> to work on top of Mono.
>>
>> Up until now, the code was living in mono-soc-2008 repository[1] hosted on
>> Google Code. Since .NET 4 beta has been released (and as it bundles
>> ParallelFx into the BCL [2]) it seems about time to move the development of
>> ParallelFx into Mono trunk with the 4.0 profile.
>>
>> The patch (http://is.gd/1P4n7) contains 2 of the 3 parts of ParallelFx :
>> the TPL (Task Parallel Library) and DSC (Data Structures for Coordination).
>> Modified/added namespaces are `System.Threading', `System.Collections.Concurrent'
>> and `System.Threading.Tasks'.  The last component, PLinq, is working but
>> hasn't yet been ported to the 4.0 API and thus isn't suitable for
>> integration.
>>
>> It's quite a big patch but I would very much welcome any input on it and
>> especially if it's ok for inclusion. As you will see, some parts are still
>> unfinished but the point of the patch is to move the code into trunk and to
>> avoid duplicate efforts by other Mono developers who would think the code
>> isn't existing.
>>
>>
> The patch is just ridiculously huge to be reviewed. No one will even bother
> with a 12 thousand monster. I suggest you to split them into smaller chunks
> so we can discuss about them. My take is that you should start with the
> trivial bits (such new intertaces) which can be reviewed quite fast, then
> move to simple ones like new exceptions and other simple types and do the
> complex parts later.
>
> A quick check shows a bunch of interfaces and exceptions. There is some
> junk like class/System.Core/System.Threading.Tasks/Internal/.svn/entries
> that doesn't belong to a patch.
>
> The patch, as is, can't be reviewed as it's too big to have someone make
> sense of it. And even after comments, it will be hard to review how those
> were applied.
>
> So here is my suggestion, can we start with System.Collections.Concurrent?
> Send a patch per new public type and we can start reviewing it.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20090727/1ccc5763/attachment.html