ncupper / protobuf-net

Automatically exported from code.google.com/p/protobuf-net
Other
0 stars 0 forks source link

Serialization Support For .Net 4 Concurrent Namespace (ConcurrentQueue, Bag, etc) #354

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Please include an e-mail address if this might need a dialogue!
==============

What steps will reproduce the problem?
1. Serialize anything in the .Net 4 Concurrent Namespace such as 
ConcurrentQueue or Bag
2.
3.

What is the expected output? What do you see instead?
In a perfect world, these collections are also supported since they are the 
recommended approach for apps that do heavy lifting. Presently they do not 
serialize and raise an exception stating such.

What version of the product are you using? On what operating system?

Please provide any additional information below.

What do I need to do to talk you into support for these :) My latest app needs 
the concurrent functionality and BinaryFormatter,etc.. isn't so appealing.

Original issue reported on code.google.com by bviller...@gmail.com on 28 Jan 2013 at 9:54

GoogleCodeExporter commented 9 years ago
Actually, ConcurrentBag<T> works fine, because it implements `IEnumerable` and 
has an `Add` method, which is one of the supported scenarios. 
`ConcurrentQueue<T>` does *not*, because it doesn't have those. However, I 
support we could look for the `IProducerConsumerCollection<T>` interface and 
use `TryAdd`

Original comment by marc.gravell on 28 Jan 2013 at 10:21

GoogleCodeExporter commented 9 years ago
For info, with only a couple of changes I have it working for everything except 
stack (which gets inverted); a quick validation shows that Queue<T> and 
Stack<T> are not supported in the non-concurrent code; for now (to avoid 
issues), I propose to make the concurrent Queue/Stack equally unsupported, 
while I think about sane ways to implement it (probably using the TryTake 
method) - but bags and collections should work

Original comment by marc.gravell on 28 Jan 2013 at 11:10

GoogleCodeExporter commented 9 years ago
I would be most grateful for the ability to support the ConcurrentQueue as I've 
become quite dependent on it lately. 

TryTake will remove the item from the queue, but you can access the items by 
index MyQueue(1) or maybe CopyTo an array or other collection. I'm not really 
sure about the underpinning of what you do here so I'm a bit out of my element 
making a suggestion.

Original comment by bviller...@gmail.com on 28 Jan 2013 at 10:24

GoogleCodeExporter commented 9 years ago
Just saying... there *is* an existing way to do this...

    public ConcurrentQueue<int> Items {get;set;}

    [ProtoMember(n)]
    private int[] Items
    {
        get { return Items.ToArray(); }
        set { Items = new ConcurrentQueue<int>(value); }
    }

I agree TryTake looks like a bad choice here, so I'll count that out - but the 
index approach also looks like the type of special-case code I've tried very 
hard to avoid ;p

Original comment by marc.gravell on 28 Jan 2013 at 10:34