On 17.03.11 13:09 , "ext Tristan Gingold" <ging...@adacore.com> wrote:
>On Mar 17, 2011, at 11:28 AM, François Revol wrote: > >>From the content of the functions called it's either one of the added >>fds which cause problem on select() (but why ?), or likely some signal >>masks which interfere with some internal thread in the process. >> >> I sampled the process and took some screenshots without and with the >>#if 0 hack: >> http://revolf.free.fr/osx/shots/shot_qemu_init_main_loop_if0.png >> Things work but oddly what is supposed to be an internal dispatcher >>thread ends up executing qemu code. The main thread includes lots of >>calls from arbitrary addresses indicating it receives some signals. >> >> http://revolf.free.fr/osx/shots/shot_qemu_init_main_loop_if1.png >> Things stale, and there are 2 more threads that wait, and the main >>thread seems quite stuck in select(). > >Yes, I have to investigate that... >From what I've found out so far is that the sigwait_compat() function in compatfd.c will block all signals with sigprocmask() call and then wait for a single signal in sigwaitinfo() (forgot what it is). Sounds a bit odd to me but perhaps there's a reason for that? I tried changing the sigprocmask() call so that it only blocks the same signals that it will later wait for and things start rolling again. Regards, Juha
