On Monday 26 November 2007 11:49:05 Wim Dumon wrote:

Hello Duncan and others,

We, the developers of Wt, are a bit surprised to see your efforts on integrating Wt with Yast causes crashes and other problems (we followed your progress on the yast mailing list and the comments on your blog). Normally, Wt runs uber-stable (e.g. on our public site) and we want to keep it that way, so we're very eager to know what exactly caused the crashes so that we can catch and fix the bugs. We picked up something about Wt's thread model being incompatible with Yasts use of threads. Therefore, we have patched Wt so that you can disable all use of threads completely (in our CVS version). Could you provide us with some insights about your architecture and how you integrate Wt? We may be able to help you out so that Wt and Yast become good friends (e.g. by implementing something similar to QSocketNotifier?)

For me QSocketNotifier was the missing part, as Qt offers a way to react to a socket event while still integrating the event loop. Also, is there a way in Witty to get into and out of the event loop? Anyway, in case of getting further, we still faced some basic design problems, like the UI having to run as root, unless we used fcgi, for which there too many missing pieces in YaST (authentication?) Duncan -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Hi Wim! Cool to see you here! Dňa Monday 26 November 2007 11:49:05 Wim Dumon ste napísal:

Hello Duncan and others,

We, the developers of Wt, are a bit surprised to see your efforts on integrating Wt with Yast causes crashes and other problems (we followed your progress on the yast mailing list and the comments on your blog). Normally, Wt runs uber-stable (e.g. on our public site) and we want to keep it that way, so we're very eager to know what exactly caused the crashes so that we can catch and fix the bugs. We picked up something about Wt's thread model being incompatible with Yasts use of threads. Therefore, we have patched Wt so that you can disable all use of threads completely (in our CVS version).

Could you provide us with some insights about your architecture and how you integrate Wt? We may be able to help you out so that Wt and Yast become good friends (e.g. by implementing something similar to QSocketNotifier?)

The biggest issue I've faced was the fact that almost every functionality in the Wt classes went down to figuring out the session, and this info seems to be depend on the boost thread-local storage. So, I needed to be very careful in which thread I'm running, creating additional overhead. YaST has a base component library, which provides the main() function. This function evaluates the commandline arguments, picking client (typically YCP code) and server (typically UI). In threaded example, YCP code is started and when it first encounters UI call, it calls the UI component (*). The component then finally creates a real UI, starting a thread to handle events and redraws (call it UI thread). Every UI call from YCP synchronizes with the UI thread via 2 pipes implementing message passing, the real UI functionality is always evaluated in the UI thread. Now, we need to get Wt session management into this somehow, as the Web server is another server, so the UI component based on Wt needs to be a server for 2 sides: for YCP calls and for HTTP requests. The approach was to spawn a thread running Wt::Run() to handle the sessions and within the session I've created a timer, looking for work from YCP. This way, I was able to show a popup from time to time (1 out of 10 tries). Stano (*) In the total desperation, I've inserted a complete Hello.C at this point, running Wt::Run, and this means stopping the rest of YaST. But even this was giving me corrupted memory. -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org