lnobad / lidgren-network-gen3

Automatically exported from code.google.com/p/lidgren-network-gen3
0 stars 0 forks source link

NullReferenceException if SynchronizationContext is not set on registration of callback #77

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?

Use NetPeer.RegisterReceivedCallback in simple asynchronous example. Do not 
create or set a SynchronizationContext when calling RegisterReceivedCallback.

What is the expected output? 
Registered callback is executed when incoming message is received.

What do you see instead?
Null pointer access violation when referencing invalid context.

What version of the product are you using? 
lidgren-network-gen3-2011-06-27.zip

Suggest the following changes to allow callback on existing thread if 
SynchronizationContext is not set (better than nothing):

--- NetPeer.Internal.cs 
+++ NetPeer.Internal.cs 
@@ -68,8 +68,13 @@
  if (m_receiveCallbacks != null)
  {
-     foreach (var tuple in m_receiveCallbacks)
-         tuple.Item1.Post(tuple.Item2, this);
+   foreach (var tuple in m_receiveCallbacks)
+   {
+     if (tuple.Item1 != null)
+       tuple.Item1.Post(tuple.Item2, msg);
+     else if (tuple.Item2 != null)
+       tuple.Item2(msg);
+    }
   }

Original issue reported on code.google.com by abbott.t...@gmail.com on 11 Jul 2011 at 5:47

GoogleCodeExporter commented 9 years ago
User code processing received messages on the library thread is bound to create 
difficult-to-find bugs. There are many other ways to retrieve messages better 
suited to applications without a synchronization context. However, I just 
checked in revision 253 which contains a better exception than a null ref 
exception.

Original comment by lidg...@gmail.com on 18 Jul 2011 at 9:11

GoogleCodeExporter commented 9 years ago
Ok agreed.   I was looking for asynchronous notification of received messages 
without using any polling loops and this appears to be it in this library.  I 
have not checked current code but I think and InputQueue<T> would be a 
reasonable class for that which is what I am piping the results of this event 
through (to avoid locking the library thread).  (Search WCF samples for that 
class if interested).

Original comment by abbott.t...@gmail.com on 18 Jul 2011 at 10:01