Difference between revisions of "Architecture/Proposal/Advanced Threading-Architecture"
From Apache OpenOffice Wiki
m (Refined code sample.) |
m (→Problem: wording) |
||
| (19 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | + | Type: Proposal | |
| + | State: draft | ||
| − | + | The advanced [[Uno/Term/Threading-Architecture|threading-architecture]] aims to solve OOos scalability and responsiveness problems. | |
| − | ;Pros | + | ==Problem== |
| − | * Not calling blocking system calls leads to 'short' lasting mutex acquisitions. | + | A brief list of problems we face: |
| + | * Sometimes 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, while loading or saving a document. | ||
| + | * Scalability with multiple clients doing API calls, only one API call can be in execution at any time. | ||
| + | * Most long lasting operations such as loading, saving, printing etc. are not interruptible. | ||
| + | |||
| + | ==Solution== | ||
| + | OOo must be changed to be purely event / callback driven. Please see [[Wikipedia:|Wikipedia]] for what [[wikipedia:event-driven programming|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 [[Uno/Term/Threading-Architecture|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. | * 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=== | |
* (assumed to be) Hard to implement. | * (assumed to be) Hard to implement. | ||
| + | Pseudo Code for event loop: | ||
| + | <source lang="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; | ||
| + | } | ||
| + | </source> | ||
Graphical overview:<br> | Graphical overview:<br> | ||
[[Image:Spec_Architecture_Threading_Advanced.jpg]] | [[Image:Spec_Architecture_Threading_Advanced.jpg]] | ||
| + | |||
| + | |||
| + | [[Category:Architecture]] | ||
| + | [[Category:Draft]] | ||
| + | [[Category:Proposal]] | ||
| + | [[Category:Multi-Threading]] | ||
Latest revision as of 11:36, 5 May 2008
Type: Proposal State: draft
The advanced threading-architecture aims to solve OOos scalability and responsiveness problems.
Problem
A brief list of problems we face:
- Sometimes 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, while loading or saving a document.
- Scalability with multiple clients doing API calls, only one API call can be in execution at any time.
- Most long lasting operations such as 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:
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;
}
