XWidgetSoft Forum

XWidget & XLaunchpad , Desktop customization
It is currently 2017年 Nov 23日 03:04

All times are UTC - 8 hours




Post new topic Reply to topic  [ 5 posts ] 
Author Message
PostPosted: 2017年 Jun 21日 04:41 
Offline
User avatar

Joined: 2013年 Jul 29日 09:13
Posts: 572
As all the Xwidgets run within the context of the same process, high cpu usage in one widget can cause a drastic slow-down in all the others. When the host o/s dynamically lowers the priority of the xwidget process (a normal thing to do in a time-sharing system), all the widgets will appear to pause/hang for a period until the CPU contention is resolved in Xwidget's favour.

In comparison, due to its architecture and the way each yahoo widget runs in its own process, the yahoo widget engine is much more stable and if a widget ever does crash, it doesn't take all the other widgets with it. If a yahoo widget consumes too much cpu, other widgets will only be affected in the way that all processes will be affected, they won't instantly freeze or appear to hang. The negative side is that each independent yahoo widget consumes more resources than an Xwidget.

However, if you have a powerful and modern PC with a decent processor and plenty of memory (most do these days) the amount of resources that these widgets consume is really quite trivial on a modern quad core 3+ghz system. The system I am using now is an old core2duo, 2.5ghz machine and the load of running the xwidget and yahoo widget engines simultaneously with 20 or so widgets is low if not negligible.

Due to the way that all Xwidgets run within the same context, I find the stability of the Xwidget engine is questionable, especially when developing a new widget and running multiple other xwidgets simultaneously. When running highly animated gauges, the dock can become paralysed and sometimes your widgets refuse to initialise. Killing Xwidgets altogether seems to be the only solution. It is actually useful having a Yahoo widget that is designed (a big kill switch) to actually kill and restart Xwidgets and vice versa!

An architectural change is required within Xwidgets that allows the widgets to be run independently within their own process. This would bring stability to Xwidget.


Top
 Profile  
 
PostPosted: 2017年 Jul 7日 01:07 
Offline
User avatar

Joined: 2013年 Jul 29日 09:13
Posts: 572
The editor and the debugger run within their own processes distinct from the standard xwidget process. Therefore you can kill xwidgets and find that the IDE and the xwidget you are debugging is still running on your desktop. This isn't a bug. It shows that widgets can be run within their own process. This is already part of xwidget. There needs to be a way of configuring xwidgets to allow all widgets to operate in the same fashion. Each widget running within its own process.


Top
 Profile  
 
PostPosted: 2017年 Oct 2日 00:23 
Offline
User avatar

Joined: 2013年 Jul 29日 09:13
Posts: 572
Individual processes per widget is an essential function for Xwidget to operate in a stable fashion. During system startup if xwidget is set to autorun, then Xwidget has to compete for cpu with other processes. Occasionally, one or more of the widgets will refuse to initialise and Xwidget does not quite complete its own startup due to all the processes (including the stalled process) running within the same context. An xwidget restart is then required to sort out the stalled startup.

If each widget had its own process then one widget stalling would have no effect on the rest of the engine. The good thing about having pre-existing competitive widget engines is that many of the architectural design issues have already been determined so all any potential widget engine dev has to do is - to do what those engines have already done. Look to the yahoo widget engine and see what it does well, copy that.


Top
 Profile  
 
PostPosted: 2017年 Oct 3日 04:56 
Offline
User avatar

Joined: 2013年 Jul 29日 09:13
Posts: 572
Whenever Xwidget has an instability then it affects all other widgets. This is an architectural mistake. One widget looping/stalling should NEVER affect other widgets.

In other more mature engines, if one widget has an issue then you can simply kill the rogue widget.

Suggestion: If the engine is ever modified to allow running one process per widget then the process name should consist of the widget name + xwidget.exe ie. mediaPlayerXwidget.exe this allows identification of the offending widget in task manager meaning that it can be easily identified and shutdown.


Top
 Profile  
 
PostPosted: 2017年 Nov 4日 08:09 
Offline
User avatar

Joined: 2013年 Jul 29日 09:13
Posts: 572
A side effect of this 'feature' is definitely is a bug that results in unwanted behaviour...

Some of my widgets fail to respond over time, namely the network i/o gauges. The cores seem to stop returning the information to the widget periodically. To get round this I have a timer set on the widget so that if the widget fails to register any i/o for a set period of time it reloads itself, or restarts.

When the widget restarts ALL the widgets come to the fore in front of any application that is running. This is due to the fact that all widgets are connected and run within the same process space. As the restarted widget initiates it comes to the fore bringing all the other widgets with it. This is unwanted behaviour.

For several good reasons each widget should be able to run in its own process. Any process function or malfunction would not adversely affect another running widget.

The way the Xwidget currently operates could be seen as one big bug, at best a feature with unpleasant side-effects. We need the option to run one widget per process (as per the widgets being edited) or as it is today.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 

All times are UTC - 8 hours


Who is online

Users browsing this forum: No registered users and 9 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  

Powered by phpBB® Forum Software © phpBB Group