[Mono-dev] Mono hangs on shutdown when /dev/ttySx ports were opened.

[Zoltan Varga]

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 <skolima at 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 <vargaz at 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_hoff at 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 at lists.ximian.com
> >> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20090922/8d0067bd/attachment.html