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