Sorry for very late replay. On Mon, 3 Jun 2024 15:20:32 +0200 Johannes Khoshnazar-Thoma wrote: > We did more testing and it looks like the name of the event > that signals console master thread start and end is shared between > unrelated processes (it uses the console minor which is always (?) > 0 when running from a powershell). > > So since it is a two-state event (as opposed to a semaphore) > in theory the following can happen: > > Process A Process B > SetEvent(e) > SetEvent(e) > Waitforevent(e) > Waitforevent(e)
This should not happen. Master thread is unique to console. get_minor() number is always 0 for the first opened console. If you open another powershell window and start cygwin process while the first cygwin process is still active, the get_minor() returns 1. Waiting for thread_sync_event is executed only if (shared_console_info[unit] && con.owner == myself->pid) con.owner is in the shared memory which is shared among all processes started in the same console. Therefore, only the one process start to wait the event. > The second SetEvent does nothing. As a result the > later Waitforevent is stuck (which is what we observe). > > So the question is: why should this event be used in > unrelated cygwin processes? Is there a technical reason > we don't understand (yet) for doing that (sharing the event). > > We patched cygwin to use pseudo random event names (the > tm_usec field of gettimeofday()) and the stuckness vanished. > So unless there is a reason for sharing the event between > cygwin processes this patch should work: Do you really confirm that your patch resolves the issue? If so, the cause might be some kind of race issue. -- Takashi Yano <takashi.y...@nifty.ne.jp> -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
