Threads please

I like to use these blog posts to put out my experiences while working with webOS on gDial Pro and also to lobby for what I want as a developer from the Mojo SDK.

If you know Javascript, then you know that it is single threaded. (Except for WorkerPool in Gears)

For most usage cases this is no big deal as it offers plenty of asynchronous functionality and by being single threaded you can avoid some of the thorny issues with locks, etc that threads bring with them. This is a good thing. The problem I am currently having is that Javascript is now being used for a full application which consists of a User Interface and then other operations that run in the background at various intervals.

With a single thread, I have had to do some copious balancing of work being done by the program and leaving processing open for the User Interface to remain responsive. The type of work being done in the "background" is searching contacts for universal search, loading new history, loading new contacts, etc. This is stuff that is coded in gDial Pro and so asynchronous is not enough. I have had to wrap what should be step by step logic into asynchronous mish-mash to keep any of the logic from interfering with the User Interface so that users don't see a laggy interface when clicking buttons, seeing a spinner, and anything else.

Just to give some perspective on this, if you do a loop through 300 items and don't do much work at all in the loop, it will lock up the UI during this loop. The spinner stops, clicks don't work, nothing. On a desktop this isn't an issue as the loop takes almost no time, but on a mobile device like the Pre or Pixi, well you get the point. The time taken to process is longer and so is the unresponsiveness then of the UI unless you break this loop up into an asynchronous process. That leads to questions like how many iterations should I do before returning control to the UI....This starts to sound an awful lot like writing a thread scheduler without know what other threads are running in the OS.

My point of this post is to convince Palm to implement something like the WorkerPool from Gears into the Mojo SDK. Some people would say why add threads when you can code around it, but from my perspective, let me choose to use a more advanced tool like threads if I need them, and I REALLY NEED THEM. I would rather keep the logic of my code straightforward and let it run in a low priority thread then try to do my own thread management using asynchronous callbacks (This is not fun by the way).

I spoke with some engineers at Palm about this while out there for the Sprint Developer Conference, but please make it a priority. Complex apps would be easier to write with threads or something simulating threads. Even if it continued to be a single thread but with scheduling built into the webOS piece that would be fine (ie yield support). Just don't force me to schedule threads as I don't have access to know what else is happening on the device to do it and I really don't want to anyways.

For the time being I will continue to simulate threading where it doesn't exist.