Decoupling from multitasking
The old WIMP combines the context switcher, the memory manager and the GUI, but here it is reduced to just a GUI subsystem. It will not deal with process swapping generally. The new WIMP is synonymous with the GUI.
The new WIMP might impose certain restrictions to make sure that legacy applications don't notice that they are running in a new environment.
WIMP tasks and switcher processes have distinct identities. (In other places in this site, I've rather sloppily conflated the two terms. [Edit: Must fix that.])
Any thread can register as a WIMP task, so a single process could register as two distinct tasks.
A thread can only call WIMP operations if it has already called Wimp_Initialise. These operations only apply to the task identity obtained by this earlier call. Other threads in the same process will either have to register as distinct tasks (which might not achieve the desired intent) or communicate internally with the registered thread to do something WIMP-related on their behalf.
Legacy applications won't be bothered by this restriction, as they won't be running any kernel-supported threads.
The GUI subsystem has some sort of token [Edit: There's a better word!] which it gives to exactly one thread. Only the thread with the token can call WIMP operations. It can only be passed to another thread by the first one calling Wimp_Poll and blocking, allowing the second to unblock from an earlier call to Wimp_Poll.
If other applications refrain from screen operations while they don't have the token, the long redrawing operations made by the one that does have it will be able to be pre-empted while allowing non-WIMP threads to do useful work.
Question: Is there a risk of deadlock here?
Erm…? Dunno.
The GUI subsystem ought to be able to retain the message-acknowledgement semantics that are vital to communication in legacy applications (and probably in new ones too).
Question: Do all WIMP operations have to be restricted?
No. Perhaps only calls to Wimp_UpdateWindow and Wimp_GetRectangle need to be dealt with. They are used only on occasions when applications access the screen.
[Edit:
Of course, there's another way to redraw your window while allowing WIMP activities in other apps. When you receive Redraw_Window_Request or call Wimp_UpdateWindow, you repeatedly call Wimp_GetRectangle, and record all rectangles. On each null event, pick a rectangle, and call Wimp_UpdateWindow on it. Of the rectangles that come back, plot the first, and record all the remaining with the others you had before. If nothing else has drawn over your recorded rectangles in the meantime, you'll get back just one rectangle per Wimp_UpdateWindow, so your record of rectangles will be reduced. Otherwise, you'll get more rectangles, but covering a smaller area — the area that was covered in the meantime won't be returned to you, and you don't have to draw it.
If another window moves to reveal one of your areas, you'll have to redraw it twice. Or you could try to merge the new rectangles with your own, that you haven't yet got around to redraw. You'd have to do something similar with any independent Wimp_UpdateWindows you did yourself.
You'd also have to keep track of which rectangles had had their backgrounds repainted, as a result of Redraw_Window_Request.
]
Question: How should new WIMP applications exploit threads (without forking)?
One thread registers as a WIMP task. Other threads do the things that have strong timeliness requirements, like moving data between a network buffer and a sound buffer. They won't be constrained by the one-task-accessing-screen restriction, but will leave notes for the task to pick up to keep its display correct.
Question: How should new WIMP applications exploit forking?
When a process containing a task thread forks, the child thread should not assume that it is a task (otherwise, it would have to talk to the WIMP to find out its new task handle and window handles), and should fail on the next WIMP call, or receive a signal.
Forking as a WIMP task is, therefore, probably inadvisable (but remains possible). So the application might adopt this strategy: fork once before registering as a task, while keeping in touch with the child process. Only the parent registers, so the child can do all the forking, and never has to contain any special WIMP structures (as defined by wrapper libraries, etc). Parent and child could keep in touch via pipes (for small amounts of communication) and shared pages (for bulk transfers).
This will be the WIMP interface, but with the following alterations or additions.
[Edit:
The two new calls might turn out to be useless, but that's not too bad. The original Wimp_Poll and Wimp_PollIdle calls will be preserved for legacy applications, while new ones might benefit from using a separate thread for calling the same SWIs.
]
| Type | Routine |
|---|---|
| SWI operation | Wimp_Initialise |
| SWI operation | Wimp_ProactivePoll |
| SWI operation | Wimp_PollAcknowledge |
Prepare to receive WIMP event
This call duplicates the functionality of Wimp_Poll and Wimp_PollIdle, but it doesn't block. It immediately returns an application-event handle, as used by EventManager_ParallelWait. If a WIMP event occurs, the event handle will appear in that call's output, and the WIMP event code will appear at R1, followed by the event data.
[Edit:
This isn't going to work. There's no way for the GUI to know that EventManager_ParallelWait has returned its event, so the GUI won't be able to grant the screen-access right to this thread. Even if it is told somehow, it can't know whether the thread is actually going to deal with it this time round — unless we place that requirement on all events, which I'm not happy with.
On the other hand, we could arrange for the event to have a unique priority (or use some other way) to make it the only event that gets reported.
]
Acknowledge poll event
A task should call this as soon as it has decided to use the WIMP event. If R0 is non-zero, the thread has been granted the right to perform other WIMP operations and access the screen. This right is revoked when Wimp_ProactivePoll or Wimp_Poll or Wimp_PollIdle are next called, or when EventManager_ParallelWait is called again with the application-event handle.
If R0 is zero, it should still consider other events, although this will only happen if the thread is pre-emptible or there are multiple processors.
[Edit:
This might be a bit pointless. If you have to make a second call to get a WIMP event, you may as well just call the original Wimp_Poll, having used the event multiplexer merely to determine that it won't block. Hmm, on the other hand, it could still block after the application event has been reported, for the same reasons that this SWI could return zero.
]