Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Multithreaded toolkits: A failed dream? (2004)

weblogs.java.net

Post reply on HN
Print view View original

41–50 of 64 posts

Re: Multithreaded toolkits: A failed dream? (2004)

#41

Post by pjc50 »

vidarh wrote: post #38
frozenport wrote: post #10

Well, its also a poorly motivated dream unless you have a sexual fetish for the Java style of abstraction where everything is completely independent. Who the heck wants multi-threaded GUIs? User interaction proceeds sequentially, so most objects don't require locks. The rare exceptions in my software is rendering or IO on a separate thread, and these don't nicely fit abstraction models, as mentioned in other posts th…

Anyone who has seen the responsiveness of e.g. AmigaOS under heavy load next to many modern systems might be inclined to want (more) multi-threaded GUIs. Heavy use of multi-threading to disconnect GUI updates from the actual work was essential to making that happen. AmigaOS sacrificed throughput over responsiveness all over the place (e.g. something as trivial as cut and paste from a terminal would easily involve hal…

half a dozen threads with message passing

On a single-CPU no-MMU machine, message passing looks very similar to a function call.

Re: Multithreaded toolkits: A failed dream? (2004)

#43

Post by kllrnohj »

pjmlp wrote: post #28
mike_hearn wrote: post #26

Earlier quoted context omitted.

The developers of BeOS went on to do Android and went with the single thread model, partly because BeOS had a big problems with buggy apps full of race conditions and deadlocks. Though IMO the Android API is incredibly confusing for a lot of developers. I've found very often that some devs (the more junior ones) don't understand that services and activities are just objects all hanging off a single process and event…

Those bizarre hacks help the service don't crash when the service needs to talk back to an activity that just got replaced between request/response cycle, because the user had the strange idea to rotate the phone.

If you had just used a static there'd be no need to talk to the activity directly. The bizarre hacks tend to arise because Java devs seem to consider static globals as icky.

Re: Multithreaded toolkits: A failed dream? (2004)

#44

Post by kllrnohj »

One of the things the article doesn't mention, which is odd, is that frames are precious objects that need to be produced in whole. If you have multiple threads all producing parts of the scene, when do you actually kick off the frame so that the user never sees a part of a frame? Even if your worker thread is just updating the text of a few fields when it's done, you need to batch that up into a single atomic update on the screen.

Which means you need transactions, at which point you basically have a single thread and a message queue so why complicate things internally and add all the lock/unlock overhead?

Re: Multithreaded toolkits: A failed dream? (2004)

#45

Post by pjmlp »

kllrnohj wrote: post #43
pjmlp wrote: post #28

Earlier quoted context omitted.

Those bizarre hacks help the service don't crash when the service needs to talk back to an activity that just got replaced between request/response cycle, because the user had the strange idea to rotate the phone.

If you had just used a static there'd be no need to talk to the activity directly. The bizarre hacks tend to arise because Java devs seem to consider static globals as icky.

Global variables are icky, regardless of the language.

Re: Multithreaded toolkits: A failed dream? (2004)

#48

Post by kragen »

kllrnohj wrote: post #44

One of the things the article doesn't mention, which is odd, is that frames are precious objects that need to be produced in whole. If you have multiple threads all producing parts of the scene, when do you actually kick off the frame so that the user never sees a part of a frame? Even if your worker thread is just updating the text of a few fields when it's done, you need to batch that up into a single atomic update…

Most GUI toolkits don't bother. I'm guessing you work in video games?

Re: Multithreaded toolkits: A failed dream? (2004)

#49

Post by pflanze »

mike_hearn wrote: post #26
dnautics wrote: post #3

BeOS did this fairly well, although I would say the biggest problem is when you activate the UI and the underlying app has become unresponsive... When your app crashes, you want your UI to reflect the crashed state of the app and similarly become unresponsive.

The developers of BeOS went on to do Android and went with the single thread model, partly because BeOS had a big problems with buggy apps full of race conditions and deadlocks. Though IMO the Android API is incredibly confusing for a lot of developers. I've found very often that some devs (the more junior ones) don't understand that services and activities are just objects all hanging off a single process and event…

> The developers of BeOS went on to do Android

I haven't heard of this before, so I went searching. The only pieces I could find are:

Several ex-Be employees went to work for Danger after the company told to Palm. Some of them moved on to Android, which was co-founded by Danger co-founder Andy Rubin and acquired by Google. Others stayed on at Palm, but ended up joining Google after PalmSource (which was spun out of Palm) was acquired by Access. (http://readwrite.com/2011/06/29/a-look-back-at-the-beos-file...)

Today (June 2004), Baron [Arnold] and a bunch of other ex-Be engineers are working at Danger. (http://www.osnews.com/story/7265)

So, "Baron Arnold and a bunch of others" went from Be to Danger Inc., which was acquired by Microsoft in 2008. Andy Rubin went on from there to become one of the four founders of Android, Inc., but I can't find any indication of Andy Rubin having worked for Be, and none that other people followed him from Danger.

Is there more to it?

Edit: a few more citations (still rather vague):

Many of Be's engineers moved on to a company called Danger, the company behind the Sidekick. When Danger founder Andy Rubin left the company in 2003 to found Android,[...] many of those developers went with them. (http://www.slideshare.net/newsworthy2457/this-os-almost-made...)

As for Android, Andy Rubin, the founder of Android inc and current head of Android at Google, also worked at Danger, a company where several Be employees such as Baron Arnold ended up. The Kin project, which largely inspired the UI of Windows Phone 7, was created by Danger after it became part of Microsoft. Unfortunately after Microsoft axed the OS Danger was working on, Project Pink, and the Kin was a dismal failure, nearly all of the Danger employees left Microsoft (including of course Andy Rubin), leaving little if any shipped code behind. (http://forums.sonicretro.org/index.php?showtopic=25221) (Not sure if calling Rubin "the founder" is misleading since they were 4 co-founders.)

Edit 2:

Danger were made up with more than just ex-Apple employees. A number of the engineers from Be Inc ended up there (Ficus Kirkpatrick, for example, and Baron Arnold also) and Danger was the genesis from which Android was born. (http://www.osnews.com/comments/27498?view=flat&threshold=0&s...) (Not providing details on what influence Danger had on Android other than Rubin, either.)

Re: Multithreaded toolkits: A failed dream? (2004)

#50

Post by samth »

The [Racket gui toolkit](http://docs.racket-lang.org/gui/) is successfully multithreaded, and manages this despite being implemented on top of existing non-multithreaded and non-thread-safe toolkits. It's hard, but it's certainly not impossible.

[Here's a paper](http://www.ccs.neu.edu/racket/pubs/icfp99-ffkf.pdf) about the system, and how it enables cool new stuff

Post reply on HN