Mailinglist Archive: yast-devel (129 mails)

< Previous Next >
Re: [yast-devel] Wt and Yast
  • From: Stanislav Visnovsky <visnov@xxxxxxx>
  • Date: Mon, 26 Nov 2007 16:32:51 +0100
  • Message-id: <200711261632.51673.visnov@xxxxxxx>
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

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

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).


(*) 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@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >