Hi, Yes the runtime only aborts threads which execute native code when they return to managed code.
Zoltan On Tue, Sep 22, 2009 at 11:35 AM, Leszek Ciesielski <skol...@gmail.com>wrote: > Hi, > > I'll repeat my question if you'll excuse me: > > Zoltan (or anyone else knowing how this works) could you please > explain how the mono/mono/support/*.c code should execute native > blocking calls so that the runtime can shutdown correctly? From > reading into threads.c I am now guessing that the runtime does not > signal the native threads in any way, it just waits for a managed > thread switch to inject ThreadAbortException - is this a correct > assumption? If yes, then the blocking native calls should return every > few seconds (or probably even more often) and force the managed thread > switch with Thread.Sleep() so as to give the runtime the opportunity > to terminate them in an orderly manner. I think I can fix the serial.c > code, I just have to understand better how it should behave to avoid > locking. > > Regards, > > skolima > > On Mon, Sep 21, 2009 at 2:03 PM, Zoltan Varga <var...@gmail.com> wrote: > > Hi, > > > > This is very tricky problem. The runtime waits for all application > threads > > to finish before exiting in order to have a predictable shutdown and to > be > > compatible with ms.net. If we didn't > > wait for them, and started to free up the runtime data structures, then > one > > of the running threads could access the freed data and crash/misbehave. > You > > might want to try to > > close the file descriptor the thread is waiting on, that might break the > > wait. > > > > Zoltan > > > > On Mon, Sep 21, 2009 at 10:07 AM, Christian Hoff <christian_h...@gmx.net > > > > wrote: > >> > >> Leszek Ciesielski wrote: > >> > I am experiencing Mono hangup when my application should terminate. > >> > The application opens multiple serial ports, but the bug has also > >> > manifested when network sockets were hanging on reads or writes - it > >> > seems to be related to a pending I/O operation, asynchronous > >> > networking helps somewhat. Anyway, the managed code exits, Mono CPU > >> > usage jumps to 100%, /proc/PID/status shows 4 threads and the > >> > application never exits. > >> > > >> Great to see that this issue is being actively worked on! I'm > >> experiencing the same problem with my application which uses serial > >> ports. The workaround I'm using so far is to set the read timeout to > >> something about 500. > >> > >> As you have probably figured out already, the problem seems to be that > >> Mono does not abort calls to native API. SerialPort.ReadByte pinvokes a > >> blocking function in MonoPosixHelper. > >> > >> I'm not sure if native API calls should be aborted by the Mono runtime. > >> Maybe the best solution here is to see how the func is implemented in > >> MonoPosixHelper and see if we possibly avoid the blocking native call. > >> > >> > >> Christian > >> _______________________________________________ > >> Mono-devel-list mailing list > >> Mono-devel-list@lists.ximian.com > >> http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > >
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list