Mailinglist Archive: yast-devel (129 mails)

< Previous Next >
Re: [yast-devel] Wt and Yast
  • From: "Wim Dumon" <wdumon@xxxxxxxxx>
  • Date: Tue, 27 Nov 2007 23:06:13 +0100
  • Message-id: <c62cbfb50711271406y4434fe41r2552259557f76228@xxxxxxxxxxxxxx>
On Nov 26, 2007 4:32 PM, Stanislav Visnovsky <visnov@xxxxxxx> wrote:
Hi Wim!

Cool to see you here!


It's our pleasure to see that Wt is considered for Yast.

<snip>

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.


See my other post, I think you should structure it differently so that
you don't need any thread switching at all.

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

You should accept that a single web daemon will be able to serve
multiple yast sessions, and thus it is started in a way not specific
to a particular user, but rather as a plain daemon.

The way you start yast from the command-line is on the same level as
where a particular user surfs to the daemon and starts a new session.
That will cause the 'create application' callback (argument of
Wt::WRun) to get called, from which you have to return a WApplication
object. If multiple users are surfing to the Yast website
simultaneously, multiple Yast applications are running simultaneously,
either as separate unix processes or within the same unix process,
depending on your wt deployment options.

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.


I suggest you do something like this, since it only changes the
bootstrap, and considers the YCP as a "worker" thread spawned from the
Wt event loop:

- createApplication() [in the Wt thread], creates a YCP thread, and
waits for a synchronization signal from the worker thread.
- YCP thread triggers UI code which sets up synchronization pipes and
signals the Wt thread
- Wt thread creates the WApplication and (and anything else). From
here on it should be the same story as the Qt UI, but instead of
running app->exec() method, it returns the Application instance.

Bottom line: As Wt is an 'application server', it can cause multiple
Yasts to be started (one per user surfing to the application server).
We recommend to write your program in such a way as if the 'create
application' callback that you specified as parameter of Wt::WRun() is
the 'main()' function of what you would have written in a Qt
application. The main task of main() in a Wt application is to call
Wt::WRun().

Regards,
Wim.
--
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups