home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.os.minix
- Path: sparky!uunet!paladin.american.edu!gatech!udel!louie!minix
- From: henrik@husc.harvard.edu
- Subject: Interprocess communication at user level
- Message-ID: <1992Dec31.165715.28021@udel.edu>
- Originator: mmdf@louie.udel.edu
- Sender: usenet@udel.edu (USENET News Service)
- Nntp-Posting-Host: louie.udel.edu
- Organization: University of Delaware
- Date: Thu, 31 Dec 1992 16:57:00 GMT
- Approved: usenet=relay@louie.udel.EDU
- Lines: 25
-
-
- Well, the problem is that user processes work in the opposite fashion from
- the system processes (like FS and MM), expecting to send a message and
- get a response, rather than they other way round. Recall that all user
- processes use sendrec() to communicate with the lower layers.
-
- While it would not be impossible to allow processes to send messages to
- each other directly, it would require two things - knowledge of the
- underlying message-passing interface (as opposed to the Unix system call
- library), and some measure of security (who can send who a process, etc.).
-
- In theory you might construct another user process (like a network license
- server, say) that would be modelled after MM/FS, but you would probably
- run it as part of the third layer, to avoid the problems above.
-
- If you're looking for more general IPC, you might consider implementing
- one of the more popular Unix mechanisms in terms of the message-passing
- interface rather than exposing that directly - it would have the advantage
- of portability, and would probably provide a better general framework
- than the message-passing calls.
-
- larry...
-
- --
- Mail System (MMDF)
-