- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev] Automake and dynamic linking

by Jorge Arellano Cid

On Wed, 17 Dec 2003, Jorgen Viksell wrote: > Hi, > > I've actually got a patch for this. It's just that it's part of a larger > patch to clean up configure.in. > I can split these changes out and send it to you in a couple of days. > > Jörgen Excellent! Greetings Jorge.-

Dec. 18, 2003

Re: [Dillo-dev] Automake and dynamic linking

by Jorgen Viksell

Hi, I've actually got a patch for this. It's just that it's part of a larger patch to clean up configure.in. I can split these changes out and send it to you in a couple of days. Jörgen ons 2003-12-17 klockan 20.58 skrev Jorge Arellano Cid: > Hi guys, > > I just noticed that out automake process ends linking all the > libraries required by dillo to dpid and every dpi! > > For instance: > > $ldd dpid > libpthread.so.0 => /lib/libpthread.so.0 (0x4001f000) > libpng.so.3 => /usr/lib/libpng.so.3 (0x40071000) > libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x4009b000) > libz.so.1 => /usr/lib/libz.so.1 (0x400b8000) > libgtk-1.2.so.0 => /usr/lib/libgtk-1.2.so.0 (0x400c5000) > libgdk-1.2.so.0 => /usr/lib/libgdk-1.2.so.0 (0x401e3000) > libgmodule-1.2.so.0 => /usr/lib/libgmodule-1.2.so.0 (0x40214000) > libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x40218000) > libdl.so.2 => /lib/libdl.so.2 (0x40239000) > libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4023c000) > libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4024a000) > libm.so.6 => /lib/libm.so.6 (0x40311000) > libc.so.6 => /lib/libc.so.6 (0x40334000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) > > Wow! > > And the kernel reports: > > VmSize: 4684 kB > VmLck: 0 kB > VmRSS: 1160 kB > VmData: 304 kB > VmStk: 16 kB > VmExe: 24 kB > VmLib: 4208 kB > > This means that resident dpis (servers) can end wasting virtual > memory after dillo exits by retaining unused libs in VmLib. > > If someone here can make a patch for this problem, it'd be a > great time saver. Please? :-) > > > Cheers > Jorge.-

Dec. 17, 2003

Automake and dynamic linking

by Jorge Arellano Cid

Hi guys, I just noticed that out automake process ends linking all the libraries required by dillo to dpid and every dpi! For instance: $ldd dpid libpthread.so.0 => /lib/libpthread.so.0 (0x4001f000) libpng.so.3 => /usr/lib/libpng.so.3 (0x40071000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x4009b000) libz.so.1 => /usr/lib/libz.so.1 (0x400b8000) libgtk-1.2.so.0 => /usr/lib/libgtk-1.2.so.0 (0x400c5000) libgdk-1.2.so.0 => /usr/lib/libgdk-1.2.so.0 (0x401e3000) libgmodule-1.2.so.0 => /usr/lib/libgmodule-1.2.so.0 (0x40214000) libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x40218000) libdl.so.2 => /lib/libdl.so.2 (0x40239000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4023c000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4024a000) libm.so.6 => /lib/libm.so.6 (0x40311000) libc.so.6 => /lib/libc.so.6 (0x40334000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Wow! And the kernel reports: VmSize: 4684 kB VmLck: 0 kB VmRSS: 1160 kB VmData: 304 kB VmStk: 16 kB VmExe: 24 kB VmLib: 4208 kB This means that resident dpis (servers) can end wasting virtual memory after dillo exits by retaining unused libs in VmLib. If someone here can make a patch for this problem, it'd be a great time saver. Please? :-) Cheers Jorge.-

Dec. 17, 2003

Re: [Dillo-dev] wanted: CPU overhead source.

by Jorge Arellano Cid

On Fri, 5 Dec 2003, Johannes Hofmann wrote: > Hi Jorge, > > On Thu, Dec 04, 2003 at 10:43:34AM -0300, Jorge Arellano Cid wrote: > > > > I could not yet get any reproducible results from profiling, > > > > !? > > > > Doesn't it show any function usage-ratio/run-time change? > > > > Ok, I redid the profiling on my slower Linux box with utilities.html. > > Html_cleanup_tag is called more often in cvs version (16742 vs. 10749) and > seems quite a bit slower than in 0.7.3. > > See gprof output below. > [...] This is one of those weird situations that computer programming has. If we had been working for a year to make rendering three times faster, and succeeded on the effort, it'd be regarded as a substantial achievement. Actually we had been working for four years to get every bit of speed we can into dillo, and a library upgrade that makes dillo three times slower, is unacceptable. Now, all of a sudden, rendering went three times slower because of some unknown reasons, after applying a simple patch. Profiling revealed that Html_cleanup_tag() was to blame, _but_ that function is identical in both versions! Who's to blame? The compiler, the CPU cache, the pipeline, memory handling, page faults, ... All of them? I made a guess based on our C code, rearranged it and voila!, the former performance is back. Weird world, isn't it? What should have a minor impact on performance (a few CPU cycles overhead) exceeded 0(n) algorithms by a factor of two. :-o It seems that detailed knowledge of the underlying layers plays a significant role in the overall performance of a program. This may seem obvious, but remember that the academy teachs the opposite. Caveat emptor! Patch commited. Cheers Jorge.-

Dec. 17, 2003

Re: [Dillo-dev] Re: BUG#494

by Madis Janson

On Sun, 14 Dec 2003, Trent Jarvi wrote: > > Some *BSD don't provide a reentrant gethostbyname: > > > > <q source='manpage of a BSD'> > > BUGS > > These functions use static data storage; if the data is needed for future > > use, it should be copied before any subsequent calls overwrite it. Only > > the Internet address format is currently understood. > > </q> > > > > The only one I know that doesn't work is openBSD >= 3.3. > > (produces random lookups) > > > > Does anyone know the situation better? > > It is for disabling threaded dns lookups at configure time. > > Would gethostbyname_r() solve this? > I had getaddrinfo patch, but it was done, when dillo had no ipv6 support and so it cannot be directly applied now. getaddrinfo has some advantages, but i do not know how well it is supported on different unix flavors. Although getaddrinfo is in posix standard, when gethostbyname_r imho is not. The dillo way of using gethostbyname as a re-entrable function surely isn't standard eighter, even when glibc2 supports it.

Dec. 15, 2003

Cache expire header...

by Tom Lisjac

Hi All! I've written a small, Dillo friendly wiki/cms system in php that I'm hoping to release in a few weeks. During testing (today's cvs), I found that Dillo's cache wasn't expiring the dynamic pages. Here's the header I was initially using to disable client caching: header("Expires: Sun, 22 Mar 1998 20:00:00 GMT"); header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT"); header("Pragma: no-cache"); header("Cache-Control: post-check=0, pre-check=0"); With this header, Dillo's stdout messages reported "bad clocks"... so I tried sending the same date for Expires and Last-Modified. Dillo's stdout came back with: "Forcing min expire 60 on >the url< instead 0". What does that mean? I really need the content of certain pages to expire immediately when viewed. Any suggestions for the correct header parameters would be greatly appreciated. Thanks! -Tom

Dec. 14, 2003

Re: [Dillo-dev] Re: BUG#494

by Trent Jarvi

> > > Hi, > > Some *BSD don't provide a reentrant gethostbyname: > > <q source='manpage of a BSD'> > BUGS > These functions use static data storage; if the data is needed for future > use, it should be copied before any subsequent calls overwrite it. Only > the Internet address format is currently understood. > </q> > > The only one I know that doesn't work is openBSD >= 3.3. > (produces random lookups) > > Does anyone know the situation better? > It is for disabling threaded dns lookups at configure time. > > Would gethostbyname_r() solve this? -- Trent Jarvi taj(a)www.linux.org.uk

Dec. 14, 2003

*BSD and gethostbyname

by Jorge Arellano Cid

Hi, Some *BSD don't provide a reentrant gethostbyname: <q source='manpage of a BSD'> BUGS These functions use static data storage; if the data is needed for future use, it should be copied before any subsequent calls overwrite it. Only the Internet address format is currently understood. </q> The only one I know that doesn't work is openBSD >= 3.3. (produces random lookups) Does anyone know the situation better? It is for disabling threaded dns lookups at configure time. Cheers Jorge.- PS: That's it. A thread follows with other minutiae... ---------- Forwarded message ---------- Date: Sat, 13 Dec 2003 14:26:58 +0100 (MET) From: Anders Gavare <md1gavan(a)mdstud.chalmers.se> To: Jorge Arellano Cid <jcid(a)dillo.org> Subject: Re: [Dillo-dev] Re: BUG#494 On Sat, 13 Dec 2003, Jorge Arellano Cid wrote: > On Sat, 13 Dec 2003, Anders Gavare wrote: > > How typical: now I found this already mentioned in dillo's README file. > > Sorry to have bothered you. :-) Still, this is something that should > > be detected and taken care of by the configure script... > > Thanks for the info. > > Can you send me a patch for configure.in? Unfortunately I don't think I'm familiar enough with neither Dillo nor the configure system to add such a functionality. It took several days for me to track down the widget bug (#494), and several hours of testing to figure out this gethostbyname() bug. > Or at least the contents of the detected $target variable on > your machine (an extra line with "echo $target" after > AC_CANONICAL_SYSTEM will tell). sparc64-unknown-openbsd3.3 The same problem should exist in other BSDs as well, but I've not actually seen the symptoms. The manpages of FreeBSD 4.5 and NetBSD-current (after 1.6.1) have the following in their gethostbyname(3) manpages: BUGS These functions use static data storage; if the data is needed for future use, it should be copied before any subsequent calls overwrite it. Only the Internet address format is currently understood. Imho, if Dillo aims for platform independance, which is one of the things I like best about Dillo, this feature (multithreaded DNS lookups) would be better off disabled _unless_ the underlying platform explicitly allows it. Not the other way around. That's my opinion, anyway. Anders

Dec. 13, 2003

Re: [Dillo-dev] Re: BUG#494

by Anders Gavare

Replying to myself... On Sat, 13 Dec 2003, Anders Gavare wrote: > Dillo's dns lookups randomly stop working. gethostbyname() isn't > reentrant on OpenBSD 3.3/sparc64. (I believe that's what causing the > random bugs.) Undefining G_DNS_THREADED in src/dns.c solved the > symptoms here. How typical: now I found this already mentioned in dillo's README file. Sorry to have bothered you. :-) Still, this is something that should be detected and taken care of by the configure script... Anders

Dec. 13, 2003

Re: [Dillo-dev] Re: BUG#494

by Anders Gavare

On Wed, 10 Dec 2003, Jorge Arellano Cid wrote: > On Wed, 10 Dec 2003, Anders Gavare wrote: ... > > entry from the bug database. I've not had any other problems on sparc64 > > yet, except possible some random lock-ups. The version in CVS as of > > 07:00 this morning seems to work just fine (that is, it still has the > > random lock-ups but the output looks nice). > > lock-ups... Can you decribe them some more, or better, run > dillo under gdb to find out where or why it locks (I haven't > seen that bug ever). Dillo's dns lookups randomly stop working. gethostbyname() isn't reentrant on OpenBSD 3.3/sparc64. (I believe that's what causing the random bugs.) Undefining G_DNS_THREADED in src/dns.c solved the symptoms here. > PS: Are you on dillo-dev? No. Anders

Dec. 13, 2003