I have a problem to use an Enumerator in the unmaneged world.
When I execute MoveNext() it doesn't return the expected value (true).
example code:
(an extension to Roberts code here:
http://go-mono.com/forums/#nabble-td1538089)
c++-code:
http://pastebin.com/aMHmnHRC
c#-code:
Hi,
Enumerator is probably a valuetype, and those have to be unbox-ed before
passing them to mono_runtime_invoke ().
Zoltan
On Mon, Apr 4, 2011 at 2:10 PM, viktor.hermansson
viktor.hermans...@gmail.com wrote:
I have a problem to use an Enumerator in the unmaneged
W dniu 2011-03-30 22:07:45 użytkownik Miguel de Icaza mig...@novell.com
napisał:
While another one is doing an equality test, the state is half-built.
The way you could instrument this is to rewrite that routine to not be
recursive, but instead to be iterative, and have a maximum count,
Hi,
I've not seen anything like that myself, but I'll admit we haven't run NaCl
Mono through many production level environments yet, so there may be
something there that's been previously undetected.
However, we've run embedded in Unity3D (their entire scripting engine uses
Mono) and only had to
Aren't event handler methods emitted with a [synchronized] attribute by
default which would prevent this issue? You can check by disassembling the
IL and seeing if its there.
Alan
On 4 Apr 2011 14:55, kr...@poczta.onet.pl wrote:
W dniu 2011-03-30 22:07:45 użytkownik Miguel de Icaza
On Mon, 2011-04-04 at 20:48 +0100, Alan wrote:
Aren't event handler methods emitted with a [synchronized] attribute
by default which would prevent this issue? You can check by
disassembling the IL and seeing if its there.
They are synchronized as long as you don't replace the default
On Mon, 2011-04-04 22:03:47 Gonzalo Paniagua Javier gonzalo.m...@gmail.com
wrote:
On Mon, 2011-04-04 at 20:48 +0100, Alan wrote:
Aren't event handler methods emitted with a [synchronized] attribute
by default which would prevent this issue? You can check by
disassembling the IL and seeing
On Mon, Apr 4, 2011 at 10:37 PM, kr...@poczta.onet.pl wrote:
On Mon, 2011-04-04 22:03:47 Gonzalo Paniagua Javier gonzalo.m...@gmail.com
wrote:
On Mon, 2011-04-04 at 20:48 +0100, Alan wrote:
Aren't event handler methods emitted with a [synchronized] attribute
by default which would prevent
On Mon, 2011-04-04 22:41:47 nekresh nekr...@gmail.com wrote:
On Mon, Apr 4, 2011 at 10:37 PM, kr...@poczta.onet.pl wrote:
On Mon, 2011-04-04 22:03:47 Gonzalo Paniagua Javier
gonzalo.m...@gmail.com wrote:
On Mon, 2011-04-04 at 20:48 +0100, Alan wrote:
Aren't event handler methods
Hey,
Well the other thing is that the delegate class is supposed to be
immutable. Therefore it should be impossible to produce a corrupt
delegate through multithreaded access as any modification to a
delegate instance results in a new copy of the delegate (with
modification) being created, just
I just upgraded to 2.10 and am getting strange behavior that I wasn't seeing
in 2.8.1
I call VerifyAccess in my code which is the method in the Dispatcher class
that will compare the calling thread with the thread that the dispatcher was
created on, if they differ it will throw an exception. In
11 matches
Mail list logo
