Correctly associate socket handle with its corresponding event.

[zaq32]

Fix for the https://github.com/gnu-mcu-eclipse/qemu/issues/70

Without this the event that is passed to g_source_add_poll is effectively separate and will not be signalled by the operating system once the socket is ready to be processed (due to whatever reason).

This event will be subsequently associated with its corresponding socket at during first g_main_context_dispatch which verifies the state of all handles in the poll set regardles whether it was signalled or not. This allows the system to recover but it introduces non deterministic delay between an actual event and the time when the next g_main_context_dispatch is run.

This is especially problematic when qemu is started in halt mode (-S) in which case after initial event polling main loop goes into infinite wait, waiting for connection to gdb server (or something similar to happen). The connection to gdb server however will not wake up the main loop due to the fact that event that is supposed to be monitoring the gdbstub socket is not properly configured. From this system will not be able to recover unless some other event gets fired during which state of the gdb server socket gets checked and all of the remaining pending events handled. As part of the socket evnet handling the event is reassciated with socket again (see channel-socket.c:665).

[ilg-ul]

thank you for the patch.

did you actualy tried it? I mean build a new qemu and check that it is functional?

[zaq32]

Yes I build windows version using https://github.com/gnu-mcu-eclipse/qemu-build tools and tested it in this specific scenario.

[ilg-ul]

Thank you! It'll go into the next release.