Difference between revisions of "Architecture/Proposal/Advanced Threading-Architecture"
From Apache OpenOffice Wiki
m (Improved wording, fixed some typos.) |
|||
| Line 2: | Line 2: | ||
State: draft | State: draft | ||
| − | The advanced [[Uno/Term/Threading-Architecture|threading-architecture]] aims to solve | + | The advanced [[Uno/Term/Threading-Architecture|threading-architecture]] aims to solve OOos scalability and responsiveness problems. |
==Problem== | ==Problem== | ||
The following list gives a brief overview, of where the problems lie, | The following list gives a brief overview, of where the problems lie, | ||
| − | * unresponsive user interface (e.g. trying to connect to a particular web server may take | + | * unresponsive user interface (e.g. trying to connect to a particular web server may take some minutes, without repaint and everything (it can take more time, if you have more than one http:// reference in your document) ;-), |
| − | * busy waiting (e.g. frequent re-schedule or yield calls), | + | * polling / busy waiting (e.g. frequent re-schedule or yield calls), |
| − | * scalability with multiple | + | * scalability with multiple clients, in particular when doing API programming, |
| − | * most long lasting operations (e.g. loading, saving, printing etc.) are not | + | * most long lasting operations (e.g. loading, saving, printing etc.) are not interruptible. |
==Solution== | ==Solution== | ||
| Line 15: | Line 15: | ||
The following list gives a first idea, of what should be done, | The following list gives a first idea, of what should be done, | ||
| − | * all (potentially) blocking calls need to be event driven, | + | * all (potentially) blocking calls need to be event-driven, |
* all long lasting calls need to be executed by dedicated threads, notifying the consumers via events / callbacks, in case data is available (thus basically creating event sources and event sinks), | * all long lasting calls need to be executed by dedicated threads, notifying the consumers via events / callbacks, in case data is available (thus basically creating event sources and event sinks), | ||
| − | * asynchronous signals need to be mapped to events, | + | * UNIX asynchronous signals, being an process interface by their own, need to be mapped to events, |
* Windows window messages need to be mapped to events, | * Windows window messages need to be mapped to events, | ||
* the [[Uno/Term/Threading-Architecture|threading-architecture]] must be defined high level, e.g. | * the [[Uno/Term/Threading-Architecture|threading-architecture]] must be defined high level, e.g. | ||
| Line 26: | Line 26: | ||
* Not calling potential blocking system calls leads to 'short' lasting mutex acquisitions. | * Not calling potential blocking system calls leads to 'short' lasting mutex acquisitions. | ||
* No hand crafted reschedules necessary anymore. | * No hand crafted reschedules necessary anymore. | ||
| − | * Easy utilization of | + | * Easy utilization of hyper threading, multiple cores and SMP. |
| − | * | + | * Controllable CPU utilization and possible avoidance of over utilization. |
* 'Simple' architecture. | * 'Simple' architecture. | ||
| − | * | + | * Potentially high level thread abstraction. |
===Cons=== | ===Cons=== | ||
Revision as of 08:16, 6 September 2006
Type: Proposal State: draft
The advanced threading-architecture aims to solve OOos scalability and responsiveness problems.
Problem
The following list gives a brief overview, of where the problems lie,
- unresponsive user interface (e.g. trying to connect to a particular web server may take some minutes, without repaint and everything (it can take more time, if you have more than one http:// reference in your document) ;-),
- polling / busy waiting (e.g. frequent re-schedule or yield calls),
- scalability with multiple clients, in particular when doing API programming,
- most long lasting operations (e.g. loading, saving, printing etc.) are not interruptible.
Solution
OOo must be changed to be purely event / callback driven. Please see Wikipedia for what event-driven programming is.
The following list gives a first idea, of what should be done,
- all (potentially) blocking calls need to be event-driven,
- all long lasting calls need to be executed by dedicated threads, notifying the consumers via events / callbacks, in case data is available (thus basically creating event sources and event sinks),
- UNIX asynchronous signals, being an process interface by their own, need to be mapped to events,
- Windows window messages need to be mapped to events,
- the threading-architecture must be defined high level, e.g.
- concurrency per application, or
- concurrency per document.
Pros
- Not calling potential blocking system calls leads to 'short' lasting mutex acquisitions.
- No hand crafted reschedules necessary anymore.
- Easy utilization of hyper threading, multiple cores and SMP.
- Controllable CPU utilization and possible avoidance of over utilization.
- 'Simple' architecture.
- Potentially high level thread abstraction.
Cons
- (assumed to be) Hard to implement.
Pseudo Code for event loop:
[[cpp]
void dispatch(int signal) {
switch(signal) {
case SIGIO:
fileHandler(getHandle());
break;
case SIGTERM:
...
}
}
int quit;
sigset_t sigset;
int main(void) {
int signal;
while(!quit) {
sigwait(&sigset, &signal);
dispatch(signal);
}
return 0;
}
Graphical overview:
