Palm OS Cobalt Multitasking Explained
Jeff Kirvin has written an article further explaining how the upcoming Palm OS Cobalt will handle running multiple applications at once. He also looks at the Palm OS approach to multitasking, compared with Windows mobile.
Palm OS Cobalt, formerly Palm OS 6, is a fully multi threading and multitasking OS, which means developers can create applications that operate concurrently and have tasks performed in the background. There has been a bit of bickering and misinformation circulating as to how Cobalt's multitasking will actually operate.
Jeff Kirvin, of Writing on Your Palm, has published an interesting column that should clear up some of the confusion regarding the issue. He also takes a look at how Windows mobile handles memory and multitasking. Jeff states, That said, there's some serious confusion out there about how Cobalt (the OS formerly known as Palm OS 6) will handle multitasking. I happen to think it's pretty slick and elegant, not to mention a far more efficient paradigm for resource-constrained handheld computers.
Permalink
PrintArticle Comments
(54 comments)
The following comments are owned by whoever posted them. PalmInfocenter is not responsible for them in any way.
Please Login or register here to add your comments.
Comments Closed
This article is no longer accepting new comments.
RE: Interesting...
Properly written programs bring you back to the place where you left it the last time.
The advantage of OS6 is that a worker thread can continue to do something. That's not the case for OS5 programs.
RE: Interesting...
Like, that's the point. Hello, McFly?!
RE: Interesting...
However, OS 5 apps should run just fine. Sure, they won't multitask... but they won't run any different than they do now. Right now, the apps all run as 'frontmost' threads, essentially, so that's what the OS 5 apps will do under Cobalt too. Running an OS 5 app won't kill your background threads on a Cobalt device.
We hope. ;)
RE: Interesting...
It is very easy to create a 68k version of an app to run on old OSes, and then do little to no modifications and compile it ARM native. Adding in extra Cobalt features would take a little longer.
RE: Interesting...
Peace Out
Alan
Attack of the Cobalt
http://www.palminfocenter.com/forum/topic.asp?TOPIC_ID=20678
and
http://www.pocketpcthoughts.com/forums/printview.php?t=25838&start=0
Finally
RE: Finally
1. Hardware capable of doing multiple things at once. Sure, a Dragonball VZ 66 might have done it, but probably not. This ruled out anything pre 5.0 (or should we start callingthat Garnet now?)
2. BeOS engineers. The architecture sounds an awful lot like the multithread model in BeOS ... coincidence? I hope not. BeOS was an elegant OS that was doomed to failure (MS too big, Linux too free, which left BeOS too small and too expensive).
Is Cobalt really BeOS skinned down to PDA size? I really REALLY hope so.
~ "Don't be too proud of this technological terror you've constructed." - DV ~
RE: Finally
--
Ben Combee
http://combee.palmos.com - PDA programmer weblog
RE: Finally
RE: Finally
I am not a Mac geek, but my understanding of the multifinder is that is allowed applicaiton switching, allowing you to return to an app in the same state that you left it. I certainly can't remeber being able compile in the background while having Word (MacWrite?) open in the background.
So, if you consider Multifinder multitasking, then I guess the PalmOS has had that capabiity since Palm Pilot 1000 days - switching between apps ("Home" == "Multifinder"), and entering the app where you left it. One advantage from the Mac was clicking on the window that was in the background brought it to the foreground - a luxury that the extra screen realestate the Mac had that the 160x160 display of the early PalmOS devices did not enjoy.
Bring on the true multithreaded OS.
BTW - Ben, I was not implying that direct code from BeOS was in the PalmOS, just that the engineering and experience brought over from that group has probably had a huge influence on the Cobalt design. I loved BeOS ... and I hope Cobalt will be the love child everyone is looking for.
~ "Don't be too proud of this technological terror you've constructed." - DV ~
RE: Finally
RE: Finally
IIRC, the obstacle on the 68K devices was that PalmSource did not own the kernel; they licensed it from someone else, and the terms of the agreement did not allow them to expose the threading mechanisms to anyone but the hardware licensees. (Plus, I think the number of allowed threads was very limited.)
PalmSource has been planning for this for /quite/ a while; Palm OS 5 was designed to be a stepping stone, and the Palm OS Emulator has for a long time warned developers about behaviors that would be incompatible in future OS versions.
Phasing everything out takes a long time, though, especially since, if you expect to switch to a new hardware architecture anyway, it doesn't make a lot of sense to rewrite your own kernel for the soon-to-be-obsolete one.
RE: Finally
Palm OS is a multitasking operating system. How can I create a task?
Question
Palm OS is a multitasking operating system. How can I create a task?
Answer
Palm OS is built on top of a small kernel that Palm licensed from Kadak. The terms and conditions of that license specifically state that Palm may not expose the API for creating/manipulating tasks within the OS. If you need access to these calls you need to contact Kadak at (604) 734-2796, or visit their website at http://www.kadak.com
The Palm OS ROM is built with support for a very few tasks. There are only enough task slots for the ROM's needs. In order to support more tasks the ROM would need to be rebuilt.
RE: Finally
> applicaiton switching, allowing you to return to an app in the same state that you left it.
I think you're right, but the Amiga and various Unix systems supported multitasking/multithreading on similarly powered processors (~8MHz MC68000) over a decade ago.
RE: Finally
-Enfors-
RE: Finally
RE: Finally
RE: Finally
RE: Finally
What do you mean? Cobalt does multiple windows perfectly well, in many ways better than the Amiga did.
RE: Finally
Window 1 - Calendar
Window 2 - Address book
for example. Just as Seymour can do on Pocket PC. I've been told this is not a feature of Cobalt. Tell me otherwise.
RE: Finally
Actually the list of developers is already there, you only need to find it.
> and maybe even a "Thanks to Mike Cane for the idea" line. >ROTFL!<)
I doubt that will happen :)
RE: Finally
That can only lead to confusion. :) If you want any hope of being able to have a conversation about this stuff, then we need to use the same meanings for the words. And these meanings are pretty standard:
Window -- an autonomous area of the screen through which a program can draw UI and receive input from the user.
Process -- a protected memory space managed by the kernel. Other things outside of the process can't directly access it (especially its memory). (Unless specifically granted permission.)
Application -- a cohesive piece of code that allows the user to do some task.
These are each very different concepts, and can't just be used interchangeably.
> for example. Just as Seymour can do on Pocket PC.
> I've been told this is not a feature of Cobalt.
> Tell me otherwise.
I am not going to tell you that you can just take two existing Palm OS applications and run them at the same time. We aren't at all trying to hide this fact.
On the other hand, this is as much a limitation of current Palm OS apps (or more accurately the programming model they had to work with) as it is a limitation of Cobalt. All existing Palm OS apps basically operate as if they own the device -- screen and everything. There is a lot of code in Cobalt to give those applications an environment that makes it look like they still own the world, when in fact they don't any more. But the nature of all this stuff raises a lot of very tricky questions about how you will have two of these applications running at the same time.
Consider just one example: sublaunches. I love sublaunches. Basically how they work is that while one application is running, at any time you can have it end up jumping in to some other application to have the second app do something -- from being told that a database has changed, through showing an alert because an alarm went off, to getting an exchange request and thus sitting there reading from a stream and doing stuff with the data it gets.
My group got to spend a lot of time making the higher-level part of this stuff work on a real OS. And with a lot of duct tape and baling wire, hey, it amazingly does.
Well, it works when only one of these apps is running at a time.
But now I want to run two applications that both do this kind of thing.
Okay, here they are both running: Date Book and Address Book. Beautiful.
But wait! There is an entry in Date Book that the user wants to look up, so Date Book sublaunches Address Book! (Sorry I know you can't do this in Date Book, so it's a contrived example, but the point is that any Palm OS app can do this kind of thing at any time it wants, so we have to deal with it.)
Anyway, if you remember our model of a sublaunch, it is that the current application calls into the sublaunched application. But in our example here, the application we are calling in to is already running! What do we do?!?
Well we could say Date Book doesn't know about any other running applications, so it does the normal sublaunch of Address Book. But that won't work, because now we have multiple copies of Address Book running and it was never designed to be able to do that.
Okay then, the system knows that Address Book is running, so what if we just have Date Book stop and tell the currently running Address Book to execute this sublaunch? In fact there is already some code in the system that is similar to this, to be able to sublaunch applications in to different processes (in order to enforce security), so that seems perfect!
Or does it?
Well what if, at that very same moment, Address Book is also trying to sublaunch Date Book. That would sound like a deadlock between both applications. Not good. Not to mention the multitude of race conditions between the sublaunch request and the other application possibly being in the process of starting up or shutting down. Plus there are probably going to be some applications that have problems because they never before had to deal with a situation where they got sublaunched from somewhere else while themselves the top-level application.
The point of this all being, it's not like a year ago all the engineers at PalmSource sat down, said "hey if we tell marketing we can't run multiple applications at the same time then we can take the rest of the day off," and went out and had a big party. All at your expense.
What actually happened is that this is really just a hard problem -- because of our legacy it is much harder for us than it is for Microsoft to do the same thing. That legacy is generally good, it's why we are in such a strong position in the market, and it's well worth having all those applications, but sometimes it makes things a lot harder than we'd like. But it's just part of the trade-off between keeping compatibility with old applications and being able to push the operating system forward as quickly as possible.
In the future will we support running multiple applications at the same time? Sure we will. We are starting to today, and will most definitely make things much better as time goes on. Will we some day be able to just automatically run any two traditional Palm OS applications? I don't know; we'll see what it takes to address the issues. I can say that we haven't had a lot of time to really look in to how that might be accomplished, because for 6.0 there was such a tremendous number of other issues that we were -required- to address simply to get one application at a time running on the new system architecture.
RE: Finally
You have really gone above and beyond the call of duty in not only explaining things here, but giving us a peak of the thinking behind the scenes -- as well as frankly admitting some of the shortcomings of the current OS (no Seymour-like capability -- right now).
Thank you very, very much.
Paging hackbod
I have more questions!
1) Are there guidelines on how large a SLIP 'window" can be?
2) Same thing for pinlets.
3) How are fonts installed? Can all programs draw on them -- ie, word processing, database, spreadsheet programs? Are fonts automatically smoothed? Will we finally be free of converting fonts to, say, WordSmith's Finetype format?
4) Are there any Prefs for changing UI elements? Say, changing fonts in Title bars and dialogs? Are there Themes?
5) What provisions are there for *printing*? Does PalmSource see this as something that should be integrated into the OS, or will we have to rely on third-party solutions and the tower of babel of competing 'standards" that 3rd-party developers have to choose from?
TIA.
RE: Paging hackbod
Of course not. :)
> 1) Are there guidelines on how large a SLIP
> 'window" can be?
Guidelines or restrictions? We don't really have any guidelines on this.
And in theory, there are no restrictions on size. A slip overlaps on top of any application windows as well as windows created by other threads, so it is free to cover as much space as it wants. (Though the system currently always gives it the full screen width.)
Unfortunately there is a bug in the version of Cobalt that will ship on the first devices, where the window manager wouldn't constrain the top of a slip to the top of the screen. So you have to be a bit careful about how much space you use -- worst case is a square screen with the status bar shown, giving you about 140 "dibits" of available space. (A dibit is the name we are using in Cobalt for the traditional low-density units, to distinguish it from "real" units like points, inches, centimeters.) If you aren't careful, the top of your slip can go up off the screen.
This problem has already been fixed, so following releases will do this right and correctly constrain the slip size. This will allow you to make a slip that uses all of the available space, for example, no matter how much that is.
> 2) Same thing for pinlets.
Again, no hard limits. With pinlets, though, you have to be careful about interactions with applications, because the pinlet pushes up the normal client area (i.e., the space available to normal windows). Thus:
(a) If your pinlet is unable to shrink down to the standard size, it can end up obscuring the bottom of application windows. This will happen for all existing applications, which can't deal with a screen smaller than 160 dibits. We encourage developers writing Protein applications to specify a minimum window size that is smaller than 160 dibits (if possible), so that in this situation they will shrink to make room for thhe pinlet.
(b) If your pinlet is absolutely unable to grow up to the standard size, then when running an application that doesn't support tall screens you will end up with a gap between the pinlet and the application. Fortunately it is easy to at least minimally deal with larger sizes -- just make the extra space empty -- so no pinlets should have a maximum size that is less than the standard pinlet size.
Btw, a pinlet can change its size on the fly through the normal WinSetConstraints() API, so you can do things like grow larger than usually (and possibly cover up part of the app) due to the user interacting with it. When this happens the system will automatically resize/move all application windows to conform to your new constraints.
(And slips can change their size dynamically, too -- the attention manager is now a slip and will change size when it needs add or remove attention items in its display.)
> 3) How are fonts installed?
We use standard TrueType fonts. To add new fonts to the system, you just build a standard PRC with a well known type code which has plain 'ol TrueType font files appearing in it as resources with a well-known resource type code. (I don't remember these codes, they should be in the SDK header file.) Once you put the PRC on the device and reboot, they will show up for everyone to use. (Unfortunately you currently have to reboot for the system to rescan fonts; that will be fixed in the future.)
In case that isn't clear, all it means is that there is nothing special about fonts, they're just standard TrueType font files (the exact file you find on Windows) placed into a standard PalmOS resource.
> Can all programs draw on
> them -- ie, word processing, database, spreadsheet
> programs?
There are new APIs for working with scalable fonts, all defined in the header GcFont.h. As long as an app is using those APIs, any fonts you install will be visible and usable in the application.
> Are fonts automatically smoothed?
Fonts are anti-aliased by default, though the GcFont API lets an application explicitly decide whether or not to draw with anti-aliased. (And also to enable or disable hinting.) The rendering of anti-aliased fonts is actually done by the normal Cobalt graphics system (we just get the shapes from the TrueType font and essentially use the Gc APIs to draw them), so applications have available to then that same quality of anti-aliasing for everything they draw.
> Will we
> finally be free of converting fonts to, say,
> WordSmith's Finetype format?
Yes, for applications using the new APIs. TrueType is our official font format!
> 4) Are there any Prefs for changing UI elements?
> Say, changing fonts in Title bars and dialogs? Are there Themes?
No. One of the things we were really disappointed about is that we didn't have time to update the UI even to use scalable fonts. The only things a user sees that actually use them are in the main form of the Launcher, the status bar, and a few of the slips. However, now that we have the underlying system architecture implemented, actually exploiting Cobalt's new graphics features in the UI is near the top of the list of things to do.
> 5) What provisions are there for *printing*?
> Does PalmSource see this as something that should be
> integrated into the OS,
It has certainly come up, but there is nothing I can say about plans or anything.
On the plus side, the new rendering model lends itself much better to printing (if you know PostScript, it will look extremely familiar), and the design of the Gc APIs makes this much more feasible to do. With Gc you are drawing into an explicitly specified "graphics context", which is not tied to a window. In fact, when drawing into an update-bases window, the graphics context you are drawing in to is actually not a window at all, but a special thing that turns all of your drawing commands into a stream that it sends them to another process that actually renders them.
RE: paging hackbod
More on my font obsession:
Can the 4 standard apps use the new TT fonts? That is, if I open Memos, will I still have just one face and a variety of sizes to choose from, or can I at least change everything to, say, Times?
And, yes, I understand what you're saying about PS. This is very exciting! You *must* get printing in there. That would be So Fekkin Amazing!
I will probably have more questions later. Thanks again for taking time to be here.
Paging hackbod 2
First, if you haven't, please go read
http://www.palminfocenter.com/view_story.asp?ID=2899
-- items 3 and 10 are still Outstanding. (There are others too, but these are my focus right now!)
You should see the sense of 3 right away. 64K Memos and pushbutton/jogscroll downdowndown or upupup? Nuff said.
Item 10: can't *anyone* at PalmSource see the sense of putting a "Graffiti slash" icon in the Status/Control/bottom bar? Why must, when all I want to do is Cut/Copy/Paste some text, I go through this nonsense when the DIA is retracted? --
1) Expand DIA
2) Draw slash
3) Tap icon in Command Bar
4) Collapse DIA
-- why can't it simply be like so:
1) Tap "Graffiti slash" icon in Task/Status/bottom bar
2) Tap icon in Command bar
Why doesn't that many sense?! Will you actually argue *against* that or simply admit, "Aw, shucks, none of us really *thought* of that..." I mean, doesn't the way I describe actually fit in with The Zen of Palm?!
While I've got your attention once again, let me ask some questions about the Media Player in OS6:
- exactly what kind of video files can it handle? Do you want to try to download each of these --
http://nitro.bok.net/pockettv.com/mpg/vga/
-- and see what each one does? (Actually, this test might not be worth a damn. Even if, *coughcough*, you happen to have an OS6ed palmOne device. So let me lower my expectations: If you do d/l the files, can you examine them and report if MP could handle all three?)
I'm rather keen on learning what sort of video MP will handle, especially after going through the CLIE Movie Player Gauntlet of Hell --
http://palminfocenter.com/forum/topic.asp?TOPIC_ID=21037
As for audio types, will it do Low-Bit-Rate MP3s? Specfically, LBR Old Time Radio (OTR) MP3s?
You can try, for example, any file here:
http://homepage.ntlworld.com/jaweb/page2.html
-- and while I'm at it, let me plug Mike Rohde's blog on this subject:
http://www.rohdesign.com/weblog/archives/000239.html
What provisions for DRM does the Media Player have?
Can the MP handle streaming audio/video?
More later... thanks in advance.
The fly in the ointment
First of all, ALL background threads run in the same address space. If one background thread crashes, it is liable to kill all background threads. The developer docs say that steps have been taken to restart the threads, bu you would probably lose any data or state info that was currently being processes.
Second, There is no mechanism provided to stop or kill background threads. In theory, you would do it from the app that started the thread, bu this doesn't seem like a great solution.
Outside of these concerns, the model seems really good for a memory constrained platform.
RE: The fly in the ointment
First we had a boatload of Launchers.
Now we'll have a boatload of Thread Managers.
I bet those folks at Teal are already at work on it.
RE: The fly in the ointment
Now, it may be possible to do this if developers agree on a thread information standard, where a program would store some info in a system database about threads they start and they provide a standard mechanism for the thread to determine that it should end ASAP. Since threads have their own event queues, this isn't too hard to do, but this isn't in the OS just yet.
--
Ben Combee
http://combee.palmos.com - PDA programmer weblog
RE: The fly in the ointment
You lnow, Ben, that seems to be the standard fekkin answer to almost *any* question about OS 6. I mean, WTBF were they *doing* all this time? Plus they had the effrontery to *close* their office for the final two weeks of December!
If they keep up at this pace, they'll have entire *years* of that office being closed. And it'll be their own damned fault.
And these people *still* don't see a need for an icon in the Status Bar to invoke the Command Bar. I'd call them sub-geniuses, but that'd insult Bob.
RE: The fly in the ointment
> answer to almost *any* question about OS 6. I mean,
> WTBF were they *doing* all this time? Plus they had the
Writing an OS.
> effrontery to *close* their office for the final two weeks
> of December!
That is simply not true. You are misinformed there.
> If they keep up at this pace, they'll have entire *years*
> of that office being closed. And it'll be their own damned
> fault.
Well writing an OS in two years seems pretty fast. Unfortunately while the OS supports a lot more than is shown in the APIs, there has been no time to provide programmatical access to all of the system features.
RE: The fly in the ointment
"PalmSource Director of Competitive Analysis, Crhis Dunphy, stated in an email that the PalmSource offices have been closed for the holidays between Dec 24th and Jan 4th."
http://www.palminfocenter.com/print.asp?ID=6393
So it wasn't two *full* weeks. Damned close enough.
RE: The fly in the ointment
>
>
> "PalmSource Director of Competitive Analysis, Crhis
> Dunphy, stated in an email that the PalmSource offices
> have been closed for the holidays between Dec 24th and
> Jan 4th."
>
> http://www.palminfocenter.com/print.asp?ID=6393
He is in mistake there, since offices were open on Dec 24th
(morning hours.)
> So it wasn't two *full* weeks. Damned close enough.
I look at the calendar and that is: Dec 26th, 29th, 30th, 31st and Jan 2nd. Yes 1 week is close enough to 2 weeks :-))
Seriously now. After the final stretch (anybody that works in sw industry knows what the final stretch looks and feels like) taking 1+ week of rest is not a bad thing but a necessity. I know people there that were working inhuman work schedules to get Cobalt ready.
And that been said, it is sad that the APIs do not expose yet the engine within because of trying to keep the APIs as familiar as possible to developers[1]. And that some other stuff fell through (like enabling for developers a programmatic way of enumerating background threads.)
[1] see http://osnews.com/story.php?news_id=6148
RE: The fly in the ointment
Of course you're right. I don't know what I was thinking, except it was very late when I typed that and I should have been doing something better: like sleeping! (Seems like I *was* sleeping when I typed it!)
RE: The fly in the ointment
RE: The fly in the ointment
Now freston, don't exaggerate. Some parts of the OS must have been under development for -nearly- 2 1/2 years. :)
Only the first 50 comments are displayed within the article.Click here for the full story discussion page...
Latest Comments
- I got one -Tuckermaclain
- RE: Don't we have this already? -Tuckermaclain
- RE: Palm brand will return in 2018, with devices built by TCL -richf
- RE: Palm brand will return in 2018, with devices built by TCL -dmitrygr
- Palm phone on HDblog -palmato
- Palm PVG100 -hgoldner
- RE: Like Deja Vu -PacManFoo
- Like Deja Vu -T_W
Interesting...
Peace Out
Alan