Wednesday Jun 13, 2007

Removing XInitThreads from Totem

Bastien, you're not alone. If the JDS team complained to even Sun's X11 team about bugs after they applied that Totem patch, we'd tell them they're on their own and we'd never support an application that called X from multiple threads without calling XInitThreads first.

The Solaris Xlib is thread safe (though probably with a few bugs in corner cases still) based on the same X11R6 multi-thread code as everyone else, though we're currently working to reconcile the fixes from our fork with the current X.Org code as part of our ongoing project to un-fork Solaris X11 and bring it back to the X.Org code base. We're also looking at XCB in the future for a cleaner thread-safety model as well.

Update: As noted by trisk in the comments, this seems to have been caused by known Solaris libXi bug 6551484 - the engineer who had removed XInitThreads() from totem tried the test binary produced by the engineer working on the libXi bug and found it solved the hang problem she was seeing.

Tuesday Nov 28, 2006

My favorite new feature in Nevada build 53...

I wrote a couple of weeks ago about the then-upcoming Solaris Nevada build 53 in a mail to the Solaris x86 YahooGroups mailing list:

For desktop users, nv_53 should be awesome. Gnome 2.16, Firefox 2.0, Gnome System Tools, DRI for i845/i855/i865/i915, and, just integrated today, for the first time ever, the nvidia accelerated drivers/GL as part of the Solaris OS install. Attentive viewers may note that it also doesn't have kdmconfig run at install time anymore due to the replacement of Xsun with Xorg as the install-time X server.

Now that I've updated to nv_53 on my main desktop at work (which was actually a big jump from it's previous Solaris 10 6/06 install, but went smoothly via Live Upgrade) I've found my favorite new feature is one I didn't even know about in advance - a popup menu from the JDS toolbar clock that shows the time in different timezones:

Time Zone Popup Menu screen shot

I work with people from around the world - our desktop team is mostly split between Ireland and China, with outliers in New Zealand, Canada, and Illinois. The Architecture Review Committee I serve on at Sun has members on both coasts of the US, and in India and Isreal at the moment. Trying to keep track of what time it is where is more than I can remember most of the time, so I was constantly going to to check the time in other parts of the world. Now I can add them to my menu for quick reference.

Unfortunately, it was something I discovered by accident and seems to be a little hidden - to get there, right-click on the panel clock and choose Preferences. In the Clock Preferences panel turn on Show time zones button. You should now have a big world/clock icon next to your clock like the one shown above (one that seems too large and out of place for the panel compared to the other icons there). Click on it to bring up the menu and choose Edit Time Zones. Now, you'll have to ignore the actual question shown in the next dialog:

Even though it's asking you to choose your nearest city, it really means “a city in the time zone and jurisdiction you want to see” — it's neither distance to you that matters or distance to the target, but which set of time zone rules and daylight savings change rules are in effect in the target location. For instance, if you want to know the time in Seattle, Washington, you need to choose Los Angeles, which is much farther away than Boise, Idaho or Vancouver, BC, Canada, but unlike Boise, is in the same time zone, and unlike Vancouver, follows the same national time-shifting schedule. It would be nice if it let you edit the name shown, since I normally think of needing to know the time in Beijing, not Shanghai, but it's still much nicer than what I previously did.

[Technorati Tags: , , , ]

Monday Jul 11, 2005

Can GNOME startup time be improved via ld flags?

Bryan Cantrill, Master DTrace Guru, First Class, spent some time today looking at what exactly GNOME is doing when you login to a Java Desktop System session on Solaris, and posted his findings to his weblog. (The current JDS on Solaris is based on GNOME 2.6, since that's what was the stable release last year when Solaris 10 hit feature freeze. The JDS team is working on an update to GNOME 2.10 now.)

One of the things Bryan found was that a large part of the I/O time was spent loading shared object text. I took a quick look at some of the binaries and libraries using elfdump, and noticed that there were no signs of using flags that could reduce the time needed to load shared libraries at process startup. Some of these (like -z lazyload) defer work until later - others (like -z combreloc) reduce the work needed whenever it happens.

I sent some suggestions to the JDS team on using these flags and others to improve this and suggested especially reading the Performance Considerations chapter of the Solaris Libraries and Linkers Guide for more ideas. I also cc'ed the linker gurus, and Senior Linker Alien Rod Evans added a suggestion to try out the check_rtime perl script on the binaries to check for the recommended flags and whether any of the libraries linked against aren't really needed. It's currently set up for use in the build system of the OS/Networking consolidation (the portion of the Solaris sources already released via OpenSolaris), but should be adaptable to the JDS build system or in fact, any project that wants to try to optimize it's library/linker use on Solaris.

Unfortunately, just tweaking the flags will mostly help Solaris, but the GNU binutils ld used on Linux and some other platforms offers some similar functionality - it recognizes many of the same -z options for instance, though I haven't tried them to see how they compare.

Something that may help more on both platforms is ensuring the libraries listed in the various .pc files for GNOME only list the direct requirements, not all the dependencies they depend on as well. For instance, look at what is linked into every program on Solaris that uses the gtk toolkit:

alanc@unknown:~ [2] pkg-config --libs gtk+-2.0
-lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lmlib -lpangoxft-1.0 
-lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0
But if you run elfdump -d /usr/lib/ you'll see already lists those dependencies, so duplicating them in the applications simply wastes time as the linker at runtime will load and have to check the same list of libraries it already checked in the application (though it should find it's already taken care of them and doesn't duplicate all the work). Additionally it hardcodes in the applications knowledge of the internals and backends used that they shouldn't need to know about, and makes it harder to change or replace one of them. While all those libraries need to be listed when statically linking, or on older systems (mainly pre-ELF I think), the pkg-config entries should be streamlined when using ELF shared libraries on modern systems.

[Technorati Tags: , , , ]
[Now Playing: Deep Space 9 series finale (recorded today off Spike TV by our TiVo)]


Engineer working on Oracle Solaris and with the X.Org open source community.


The views expressed on this blog are my own and do not necessarily reflect the views of Oracle, the X.Org Foundation, or anyone else.

See Also
Follow me on twitter


« July 2016