Livio,

Hello there!

I have tested today's CVS + DPI bookmarks and things seem very well!

Good! Did you use `convert` or started from scratch? Or wrote a simple script to import from elsewhere? :)

Jorge Arellano Cid writes:

[...]

...

With respect to staying alive, I also think it should end after closing dillo. Maybe sending a termination request at exit time could work fine, but I need some time to think about it...

One small suggestion is that this termination be dealt with unix signals. I don't see clearly what are the advantages of using sockets for DPI's over pipes (expect running the server and the browser in different machines, but... is that useful?).

Sockets are two-way channels and, BTW, unix domain sockets allow access from the local machine only...

Anyway, since we're using unix domain sockets, I'll assume we are local users only, and I'll also assume that signals are ok.

The advantage of using signals for termination (instead of a "proper" DPI request) is that anyone can "safely" terminate a specific server. If Dillo crashes, or if it is buggy the server may dangle alive. But if you (Dillo or a user) kill with -TERM, we can have the servers set up the termination code inside the -TERM signal handler, and hence free it's resources correctly (unsaved files, opened ftp connections, etc.).

I understand. BTW, bm_srv12 has a SIGTERM handler (just in case the server is killed or brought down with Ctrl-C). The problem is that dillo should keep track of the process ID of each server (and those can be taken down and re-launched without dillo's intervention). As you see, both schemes have some glitches; if you find an easy way to deliver the signals, I'd be all for it. Cheers Jorge.-

Melvin,

Jorge Arellano Cid <jcid@softhome.net> wrote:

...

In the meanwhile, I [...] also initialized "addrsize" as Melvin pointed out. AFAIU this doesn't affect those using GNU/Linux.

The uninitialized "addrsize" affected my system wich is a GNU/Linux 2.4.19 (+perfctr patch) using glibc 2.2.5. The compiler used is gcc 2.95.4. This is an Intel platform.

Quite interesting! My `info libc` didn't mention an explicit need to do that (except for getsockopt and getsockname); BUT the example initialized the one for accept!!! Well this isn't too surprising as the same source explains two equivalent ways to calculate the size of the address, and when tested they are different! :) Should we report that? Cheers Jorge.- PS: I'm also using glibc-2.2.5, and gcc-2.95.3.

[Sorry for the incomplete previous message] Hi Melvin, on Mon, 3 Feb 2003 19:38:25 +0100 Melvin Hadasht <melvin.hadasht@free.fr> wrote:

...

My `info libc` didn't mention an explicit need to do that (except for getsockopt and getsockname); BUT the example initialized the one for accept!!!

According to my "man accept" page, the length "should" be initialised (at least if addr is not NULL) The same source indicates that the addrlen should contain the allocated size of the structure pointed by addr (or more precisely, the sizeof() that structure). In the case of struct sockaddr_un, that size is 110, where 2 bytes are for the sa_family_t and 108 for the char array that holds the name. It seems the length is used to check if the function will not do a buffer overflow when filling it. accept() will then update the addrlen to inform the caller about the real length of the client info. In case of a Unix socket, it seems that it is used (but the string sun_path is of zero length), hence addrlen is returned with the value 2. In our case, as the client address is not used, we could just use NULL for both addr and addrlen. Anyway, in our case, libc info does not say that addrlen need to be initialized if addr is not NULL.

...

Well this isn't too surprising as the same source explains two equivalent ways to calculate the size of the address, and when tested they are different! :)

Concerning the SUN_LEN, the formula you used takes into account the trailing NUL byte of the string, which is wrong according to info libc: "You should compute the LENGTH parameter for a socket address in the local namespace as the sum of the size of the `sun_family' component and the string length (_not_ the allocation size!) of the file name string". *But* the man page says the addrlen argument to accept() should contain the "size of the structure pointed to by addr", so in this case, the SUN_LEN is not the candidate, but rather the "sizeof(struct sockaddr_un)".

...

Should we report that?

You mean reporting that accept() needs addrlen initialized if addr is not NULL? I don't know, as it seems that my system is the only one with that symptom. Farvel (Danish: Farewell) -- Melvin Hadasht

Micah,

...

Note: the new bookmarks server tarball has a short program and instructions to test permissions on *BSD machines. Someone please give it a try.

I'm using NetBSD 1.6. First, some GNUisms: Autogen.sh starts '#!/bin/bash' when /bin/sh works just fine. Convert in the dpi tarball has the same problem.

I'll fix that.

Also, Makefile.am uses the GNU-specific '--backups=t' option to install. A '-b' will make both GNU and BSD install make backups according to their default scheme. If simple backups are enough (why not?) then that's fine. Otherwise, you may have to resort to some configure trickery to decide whether to use '--backups=t' or '-b -B ".%d"' or some such. Other that that, it works great.

Is just a matter of 's/--backups=t/-b/' ? As I'm not an expert on this area, I'd appreciate a patch!

The socket test gives 'Permission denied' like it should.

Good! OpenBSD and NetBSD are OK, I only need a FreeBSD test now!

Thanks for all your work!

You're welcome Cheers Jorge.-