[interfacekit] Re: BHandler::fToken
- From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
- To: interfacekit@xxxxxxxxxxxxx
- Date: Sun, 9 Mar 2003 19:45:24 +0100 (MET)
On Sat, 8 Mar 2003, Adi Oanca wrote:
> But, there is(or may not be if I'm wrong) another catch! As far as I know,
> pointers, in user-space, are virtual; pointers in user-space begin at
> 0x00000000, and when they are used, the kernel calculates the real address
> by adding the address at witch the process resides.
I don't think there is a problem as long as the pointer is used (i.e.
dereferenced) only at the client side. For the server the pointer is just
a value, which is passed back the client.
> This means that there may be two server tokens that have the same value. Now
> we do not that to happen, so we will make a list of tokens for every
> BApplication that is launched. You may say: But wait, a token(e.g. a view)
> must be uniquely identified in the app_server!!! Well... as far as I know
> (and here, we must ask DarkWyrm!) there is no need to uniquely identify a
> token in the hole app_server (except for BApplication, that I don't know if
> it has a server token associated; I think not)! We just need to uniquely
> identify a token for all the windows and views that are associated with a
> BApplication object! Thus, when app_server spawns a thread for BApplication,
> an empty list of known tokens may be created, and when windows or views are
> added, the token list grows.
So, if I understand you correctly, you would use only the pointer. I
thought about having both, the server token and the pointer. But you're
right; if there is no need for app server global identification, then the
server token would not be needed.
I don't know much about the app server in this respect, though. Maybe
someone (DarkWyrm :-) can shed some light on what the tokens are needed
for, anyway.
CU, Ingo
Other related posts:
