On Fri, Jun 24, 2011 at 05:41:39PM +0200, Antoine Jacoutot wrote: > On Fri, 24 Jun 2011, Marco Peereboom wrote: > > > My current best theory is that the brand new link prefetch stuff (ugh!) > > is easting gobs of file descriptors while another site is loading. So > > when webkit tries to establish a connection to get like favicon or css > > it runs out and renders the pages sans css or favicon (missing pictures > > etc etc). The link prefetch can't be disabled since it doesn't have a > > knob. I am trying to reason with the webkit people (again) that > > anything prefetch is not really that great for everybody. > > Well, if there a way we could introduce such a knob in the port then?
So I misread the port and link prefetching *is* disabled. The FD use seems to stem from unclosed and/or connections that are persistent. With the port webkit one sees tons of CLOSE_WAIT connections eating FDs. It seems like webkit "forgets" to close half open connections. This is true even when destroying a webkit frame; the connections remain there until they timeout. So I compiled it with --disable-web-sockets and the connections go from CLOSE_WAIT to ESTABLISHED but it does have the appearance that sockets are reused much quicker. Web feels snappier too in my very unscientific observation. I am still playing with the options to see if I can find out how to not have any long lived persistent connections. More later. > > > In xxxterm the file descriptor starvation has other fun side effects > > because it opens and closes files left and right for things like state, > > bookmarks, etc. > > > > The easiest way to see this in action is having like 10 tabs created at > > startup. This usually results in pages not being rendered correctly and > > xxxterm complaining it can't open files. > > > > There is some evidence too that on top of this there is also a fd leak > > somewhere as well. > > > > > > -- > Antoine >
