On 04/21/2013 10:21 PM, Petr Koupý wrote: >>> Secondly, it did not take care of the window input fibril which is most of >>> the time blocked within comp_window_get_event. Note that in a normal >>> protocol-driven window closing, input fibril is already terminated when >>> the output fibril deallocates the window resources (including the queue >>> on which the input fibril is usually blocked). > >> On the other hand, I don't understand how there could be some leaked >> fibrils left after the client task is killed - the kernel will hang up >> all its phones which should lead to ending the other connection fibril >> unless it is blocked on something else. > > It is probably not clear from the original description, but the fibril was > blocked on the prodcons_t condition variable. It is waiting on any input > events adressed to that particular window. When the window is closed normally, > the whole operation is initiated by putting ET_WINDOW_CLOSE event into the > queue which starts the cascade of fibril terminations and resource > deallocations in the following order: > 1) compositor-side input fibril > 2) toolkit-side input fibril > 3) toolkit-side output fibril > 4) compositor-side output fibril > > When you kill the client task, it is necessary to wake the compositor-side > input fibril by putting a dummy event into its input queue so it can realize > the phone was hung up and terminate. At the same time, it is no longer > possible to assume the causal ordering of compositor-side fibril terminations > mentioned above, so the window resources must be deallocated by the fibril > that terminates last.
Ok, thanks for explaining this! Jakub _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
