Re: Multithreaded application freezing

On Thu, 2015-02-05 at 13:26 +0100, Göran Hasse wrote:

Den 2015-02-03 16:23, Emmanuele Bassi skrev:

On 2 February 2015 at 22:07, G Hasse <gorhas raditex nu> wrote:
Den 2015-02-02 22:57, Gulshan Singh skrev:

I strongly advice designing an application in this way.  Every window in an
application should be a separate process. Between processes you should
find a good protocol. This protocol should be transported over some message
buss. (example:

there are loads of issues with a design like that.

you're going to overengineer your application, and then have issues
whenever you have to context switch between processes because you
moved from a window to another one inside your own application.

Noop! Absolutly not! This is basic and good design. You should *separate* your
data and the program that manipulate the data. The design pattern is called
model-view-control and is well understood today.

Dont confuse MVC with process boundaries, that's not productive.

 You should have a good *protocol* to
manipulate your data. The userinterface is just a way to fire of a specific "command".
you'll have to ensure all your shared data structures are copied
correctly across process boundaries, and you'll have to have proper
bookkeeping to ensure processes do not end up using old data.

NOOP! The data should *not* be copied! You should have your data *separate* from
the manipulating program. Ever heard of the concept of a database? (The protocol here
is SQL).

That is essentially copying your data, every time that you load data
from your database, with it's in memory caches and it's ultimate
storage medium, you are creating an in memory "copy".

Depending on whether you use SQLite or a DB server, it's also going
over an IPC.

An MVC architecture does not require this, it only states that the
modal should be responsible to deliver notifications of changes,
the view should only update on those changes, and the controller should
only ever update the model and not the view directly, allowing for
any validation and consequences to occur in the model.

Many CRUD applications do this without multiple processes, and without
even having multiple windows.

you won't be able to fork() and build your UI in a child: that's not
how X11 (or any other windowing system, really) works. you'll need to
spawn a new child process from a server.

Absolutly no problem. You have a missconception of what a "server is". Any
program that listen on sockets is a server. Every GUI-program is a server. It
listen on mouse-move, key-bord-press and it is easy to have it also listen
on event on sockets.

In this application the datastore is xml (the application is using librsvg for rendering).
So I can manipulat the picture with simple xml "update" commands. And the library can
rerender the data. 

You seem to be going off on a tangent here, your claim was that:

 "every window in an application should be in a separate process"

Do you also suggest that when I popup a window with a file chooser dialog,
that I should store some intermediate state in a database, and spawn
another process to request the user for a filename, so it can then send
me back the filename over a message bus ?

That sounds incredibly convoluted, in the majority of situations
where it is uncalled for.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]