AW: "instead of going about it top-down and presuming the applications must be changed how can people change the OS to account for non-multithreading applications?"
The approach I've taken with ROLF is to start with the equivalent of the RO polling system, but extended it to allow new applications to make use of the underlying preemptive scheduling and asynchronous I/O from Linux.
Specifically, there's still Poll and PollIdle (called PollWait), which block the calling thread until the Wimp sends it an event, but there are also two more functions, Detatch and PollActive, which allow the calling thread to keep working while waiting for events from the Wimp. The former detatches the process from the Wimp so it can do anything non-screen related in the background and be informed of pending Wimp events by a signal (or selected file descriptor), the latter allows the process to continue working while waiting for the Wimp to authorise screen-related activity by the process. Also, screen redraws are requested of processes in parallel (one outstanding rectangle redraw per process).
Since the kernel is Linux, processes can also start threads, but the above allows a lot of flexibility without needing the complexity inherent in threads.
Please login before posting a comment. Use the form on the right to do so or create a free account.
Search the archives
Today's featured article
Wakefield 2009 wrap-up, photos and video The weekend's RISC OS event has been and gone and we've got the rest of our lives to look forward to. Here's a round-up of extra news and Drobe's show-related coverage and some photos taken from Wakefield 2009 - plus a video from the show floor. 16 comments, latest by AW on 29/4/09 7:41PM. Published: 27 Apr 2009