Messages in this thread | | | Date | Mon, 15 Jun 1998 13:30:31 +0330 | From | mshar@vax ... | Subject | Re: Remote fork() and Parallel programming |
| |
Hi,
alan@lxorguk.ukuu.org.uk (Alan Cox) wrote:
>Victor and for that matter a lot of the other folk. Have a good look at >the DIPC patches before you judge them. They are relatively clean, they >are very easy to program with and they definitely work. In fact I got >bored enough to rebuild X11 with DIPC XShm objects to prove the point. > >Try it, use it, judge it... > >The argument for distributed shared memory objects isnt 'should we/shouldnt >we' its 'can you take the DIPC shared memory objects and push them efficiently >into user space without kernel support. That might be possible, though I >dont think you can with the other objects it provides.
DIPC has to know about all the IPC keys in use in the cluster. An example to show this is: application A1 uses key value 100 in computer M1 of the cluster to create a "local" message queue. Now the attempt of application A2 in computer M2 to create a "global" (distributed) message queue with the same key value (100) should fail, because there will be a clash if A2 creates a process in M1 that needs to use the message queue.
Older programs use local message queues (the default behaviour of DIPC). As far as I know, unless we do some recompilations, there is no way to force these programs to use a library when creating an IPC structure; they go directly to the kernel.
If the kernel is not modified to inform DIPC's user space entities of the creation of new IPC structures, then DIPC can not work. In short, the problem is that the kernel has been the traditional service point for programs using System V IPC. The practical way to keep total compatibility (very important for me) is to continue using this interface. However, if there is a way to make sure all programs pass through a library before going to the kernel, then one can consider using it.
The case for shared memories is more complicated. Providing shared memory's strict consistency needs direct support from the kernel's memory management routines and structures. Shared memory is not used by calling a system call, so using a library is not applicable here. Managing the memory protection issues from the user space, and in a transparent way will be very awkward, if at all possible.
Considering that transparency is very important for DIPC's ease of use, I believe that any changes that damage this transparency should be avoided.
DIPC's small additions to the kernel are interleaved with the normal kernel code in a simple and understandable way. Even if the backward compatibility issues can be resolved, I think it is better, for the sake of the overall simplicity of the system, that they remain there.
-Kamran Karimi
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |