Seems that the SerialPort was a red herring - the Mono "hang on exit" occurs even when I use a "stub" SerialPort that never calls any native code (i.e. mono and mcs from svn, no DllImports in SerialPortStream.cs at all). However, I still have no idea what actually is causing the lock. Any help, please?
On Tue, Sep 22, 2009 at 6:17 PM, Leszek Ciesielski <skol...@gmail.com> wrote: > Hi, > > whenever code in mono/mono/io-layer/ performs blocking operations, it > is done in a loop like this: > > do { > ret = write (fd, buffer, numbytes); > } while (ret == -1 && errno == EINTR && > !_wapi_thread_cur_apc_pending()); > > serial.c does not include _wapi_thread_cur_apc_pending() check and > loops happily forever, ignoring all EINTRs. Is this the bug causing > the hang? I tried adding this check in appropriate places in serial.c, > however, this breaks mono at runtime with: > > mono: symbol lookup error: /opt/mono/lib/libMonoPosixHelper.so: > undefined symbol: _wapi_thread_cur_apc_pending > > The function is defined in libmono.so, which libMonoPosixHelper.so > does not link to... Am I on the right track with the > _wapi_thread_cur_apc_pending(), or does the code living in > mono/support/ just have to return to managed land in order to handle > EINTR's properly (i.e. is _wapi_thread_cur_apc_pending() usage > restricted to libmono residents only)? > > Regards, > > skolima > > On Tue, Sep 22, 2009 at 12:36 PM, Zoltan Varga <var...@gmail.com> wrote: >> 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