Topic: Widget Cycling, CPU and memory management? (for Production Model)

I noticed from another post that the production model will be opening a new thread per Flash play instance.  Does that also mean the each thread has isolated memory management?  In addition, if threads are stored in the background is the processor utilization limited?  Feel free to point me to the wiki if I over looked some documentation.

I gather that the Chumby is pretty open ended right now.  Any documentation on the widget cycles and threads would be wonderful (for the production model).  If we are not killing the various widgets threads in the background can a widget demand focus?  For instance, is a widget that checking for e-mail limited by it's cycling time?  Or can it be checking for e-mail even if it's not being displayed.  I assume that Control Panel will have to demand focus in some form.

In addition, other then using a USB hard drive is any local storage available, possible in the form of a Swap.  Is there any way that multiple Widgets can communicated with each other locally or do we need to conduct all widget communication via the web?  From what I read it looks like there is absolutely no local data what so ever (excluding the USB HD option).  I was hoping that something like the Flash ExternalInterface existed but... alas it's not part of Flash Lite2, however, read/write access would be required.  Is it possible to do any kind of temp file saving using a Unix swap folder so that widgets could talk to each other locally?

Thanks again for the help.


Re: Widget Cycling, CPU and memory management? (for Production Model)

Well, when I said "Flash Player instance", I didn't mean to imply "thread".

The Flash Lite player is essentially a virtual machine - you can create multiple "instances" of the player object within the same process and sharing the same machine address space.  The player instance makes calls intot he implementation layer for allocations of memory, network access, etc.  In the production units, the Control Panel runs in a "master" instance, and has the ability to create, run and destroy "slave" instances, which are the widgets.

There is currently no built-in mechanism for widgets to communicate with each other, and as with the prototypes, the system runs exactly one widget at a time, creating and destroying a new player for each widget.

We consider the chumby device as simply an interchangeable "player", such that any chumby could be replaced with any other chumby with no loss of any of the user's information.  This implies that nothing should be stored on the device itself except for the settings specific to operating that device - network configuration, volume, etc - and anything else that should be persistent should be stored on a server.

One problem with keeping data on the device, assuming you even have anywher to put it, is knowing when it's no longer needed.  Since a user can add and remove widgets from their channels at any time, we're too resource limited to accumulate data on the device that no longer has any purpose.

There is also no current mechanism to run persistent daemons from within Flash.  We have added functionality for the chumby to query POP3 servers from Flash, so it is possible to create a widget that monitors an email account, and we've exposed a couple of other common protocols and services.

For someone that needs more than that, the only solution we provide is the ability to run arbitrary software from a USB dongle.

Re: Widget Cycling, CPU and memory management? (for Production Model)


Are the SWF cached at all on the server or do they have to be loaded every time a widget is cycled?

Re: Widget Cycling, CPU and memory management? (for Production Model)

All widgets are served by our servers.

The chumby's Flash Player has an internal HTTP cache in RAM - the length of time something stays in the cache is determined by the HTTP header sent by the server, currently set to an hour.  Of course, if the cache is full, they might get kicked out earlier, and we may tweak the HTTP header to shape the bandwidth.