Le jeu 05/06/2003 � 18:41, Richard Eckart a �crit : > > The major issue that need to be resolved before even starting is > > defining the protocol that will be used between the GUI and the core. > > I did not have any time to work on this specification yet. I'm not > > sure I even thought out all the issues there are with the separation. > > Another problem is that to my knowledge gtk-gnutella relies very much on > it's singlethreadedness. I sure a lot of ugly race conditions will turn > up unless the gui/core protocol is very carefully designed and > implemented or you have to make all calls from gui to core blocking.
Maybe it would be 1 role more for the frontage: managing locks. This protects the single threaded design of the core. The server which uses the frontage receives multithreaded requests. Each request make the server calls to the frontage. A timout of the server detects possibly dead locks of the frontage and trace them for debugging. The timout of the TCP connection detects a client failure. This last timout does not forbid other requests to be processed. I don't really knows but object oriented encapsulation seems to make multithreading management easier. Doesn't it ? J�r�me ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. _______________________________________________ Gtk-gnutella-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
