> > 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. Petr _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
