can server side get the thread id of client side?

[fang zhengshu]

hi all,

  3. Re: can server side get the thread id of client side?
>      (Bj?rn D?bel)
> Message: 3
> Date: Fri, 28 Aug 2009 09:40:17 +0200
> From: Bj?rn D?bel <doebel at os.inf.tu-dresden.de>
> To: L4 Hackers <l4-hackers at os.inf.tu-dresden.de>
> Subject: Re: can server side get the thread id of client side?
> Message-ID: <4A9789E1.7080503 at os.inf.tu-dresden.de>
> Content-Type: text/plain; charset=ISO-8859-1
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> > I know that the client side can get the server's thread_id throw name
> > service. I want to ask can the server side get the client's task_id or
> > thread_id?
> > or must the client side send the thread_id to server?
>
> your server will call either l4_ipc_wait() or l4_ipc_reply_and_wait() in
> order to receive the message from the client. In both cases there is a
> src parameter which will contain the client's thread ID after the system
> call returns.
>
sorry for not explaining it clearly.
if I defined two functions in idl file, just like:
interface test{
int open(int fd, int flags);
int close(fd);
};

 and I implement them in the server side.
I know that when I use open()/close() in the client side, the server will
call the function open_component()/close_component() which are in the server
side.

In the open_component()/close_component() function I want to get thread id
of the caller to do some operation flag.but as we know, when we call
open()/close() in client side, the open_component()/close_component()
function in server side will be executed. so we can not use l4_ipc_wait() or
l4_ipc_reply_and_wait() function in the open_component()/close_component()
function, or it will be stop and wait for a message in the function. So in
order to get the thread id in the open_component()/close_component(), when
or where should I use the l4_ipc_wait() or l4_ipc_reply and wait()  to get
the thread id?

thank you!





-- 
fang,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20090830/8a457373/attachment.htm>