Re: mach_msg trouble

[Richard Braun]

On Sat, Nov 25, 2006 at 10:32:17AM +0200, Constantine Kousoulos wrote:
> I bypassed the previous problem using
> 
> mach_port_t rcv = mach_reply_port();
> msg_err=mach_msg(&header, MACH_RCV_MSG, 0, sizeof(header),
>                       rcv,
>                       MACH_MSG_TIMEOUT_NONE,
>                       MACH_PORT_NULL);
> 
> >Secondly, how can a client discover this server's port in order to send 
> >something?
> 
> Let me explain a bit more and correct me if i am wrong. In order 
> for two threads to communicate via mach_msg(), those two threads 
> must belong to the same task. In order for a client program to 
> communicate with an entirely different server program, mig or 
> sockets are needed. When mig is used, how can i bind my server 
> program to a specific port to listen for messages?

Not really, no. mach_msg() is used to queue messages to ports, whether
or not the receiver is a thread of the same task, or is associated to
another task. Mig is just a way to create high level RPC on top of
mach_msg().

The problem, as you could find out, is that the sender needs to know
where to send the message (it must acquire a send right on the receiver
port). When using threads of the same task, this is rather easy,
because that information is accessible by both threads (using global
variables or pointers for example) and you don't need any kind of
registering service. When threads are in different tasks, the problem
is usually solved by a server dedicated to registering ports and known
by all threads. The Hurd actually uses the file system for this (see
the Hurd function file_name_lookup()). It's not the role of Mach to
provide such a service.

See http://www.update.uu.se/~ams/notes/mach-ipc-without-mig and
http://www.update.uu.se/~ams/notes/ipc-hello.c for an example of how two
threads can use mach_msg().

-- 
Richard Braun

signature.asc
Description: Digital signature