> > Now. This might be great for a honking great shared UNIX server from the > > days of yore, but it's not remotely appropriate for a modern desktop. > > Especially not one layered with so many per-user daemons and layers of > > abstraction as we have on modern Linux systems. > > Well, one of the design points of DBus is that you only have a total > of one file descriptor for normal processes to do most IPC to others, > routed via the message bus; as opposed to say ORBit where it scales as > O(N). So adding more daemons and components shouldn't normally equate > to more file descriptors. > > In other words agree with Lennart that it likely makes more sense to > find this specific bug rather than globally increase the limit, in the > absence of other examples at least. Well, I've certainly had to bump it up to 8192 on several of the machines I run. The short version is we have a data aquisition system which records many timestreams of data. For ease of processing (and display of subsets of the data) we save each raw timestream as an individual file (using the getdata library, http://getdata.sourceforge.net/). We sometimes have run into the 1024 limit on the project I work on, and some of the projects my collegues work on always run into this (having a few thousand timestreams to record concurently). Obviously any file-descriptor leak should be fixed, but there are cases where a couple thousand files need to be opened simultaneously. -- "If you drop your keys into a river of molten lava, forget about them, they're gone!" -------------------------- Matthew Truch Department of Physics and Astronomy University of Pennsylvania matt@xxxxxxxxx http://matt.truch.net/
Attachment:
pgpsFc88Xevds.pgp
Description: PGP signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
