On Thu, 22 Dec 2011 14:42:22 -0600 "Timothy Pearson" <kb9vqf@...> wrote: > > I notice that 3.5.13 takes a long time to exit. > > > > Normally I login from the command line and start X with the startx > > script. On my 2.3 GHz dual core system with 4GB of RAM and SATA II > > hard drives, TDE takes about 7 to 8 seconds to exit and more than > > once I have seen the system take up to 15 to 17 seconds to return > > to the command line. I do not have sessions enabled, logoff > > confirmation is disabled, I don't use eye candy, apps are already > > closed, etc. > > > > My virtual machine takes about 7 to 8 seconds to exit to the > > command line. > > > > On a 350 MHz PII system with 448 MB of RAM and ATA-2 IDE hard > > drives, exit time is about 16 seconds. I expect longer times but > > not that much. Yes, a PII is not a speed demon by any modern > > standard, and such a system pushes the envelope of "old hardware," > > but if TDE is targeted for older hardware then the long exit time > > is not a good marketing point, especially on a dual core system. > > > > The dual core system uses the proprietary Nvidia drivers. The PII > > uses the tdfx driver and a first generation AGP card. > > > > For the record, 3.5.10 never was a speed demon at exiting either. I > > just expect more from TDE. :) > > > > There is an enhancement request to provide an option to disable > > displaying the "Saving your settings" dialog box, but even if > > implemented, I doubt the dialog box is responsible for the long > > exit delay. > > > > What could be the cause? Is anybody else experiencing a long exit > > delay? > > > > Darrell > > The session manager shutdown is actually a 2 or 3 phase affair, and > each phase waits for apps (including kicker, kdesktop, things in your > task tray, etc.) to shut down normally before forcibly terminating > them. There are several opportunities for delays, and debugging this > further will require an instrumented build of tdebase that can > profile the delay intoduced by each phase. > > This shouldn't be too hard to look at, please file an enhancement bug > report. I took a glance at the code and noticed some timeouts of: -4 seconds for the legacy programs shutdown -10 seconds for the protectionTimer which seems to manage libSM-aware applications If the code is thread-safe it is perhaps possible to encapsulate the performLegacySessionSave() call in a pthread_create/pthread_join, or without it we could give an option to disable the legacy session save like KDE4 does. Speaking of KDE4, I browsed the diff between the KDE 3.5.10 and KDE 4.7.4 ksmservers and found that they have similar shutdown logic so it would be nice to send any improvement patch to the KDE team :) (but regarding the graphical effects KDE4 seems to have much better and MMX/SSE-optimized code) > > Tim > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > trinity-devel-unsubscribe@... For additional > commands, e-mail: trinity-devel-help@... Read > list messsages on the Web archive: > http://trinity-devel.pearsoncomputing.net/ Please remember not to > top-post: > http://trinity.pearsoncomputing.net/mailing_lists/#top-posting >