On Fri, Nov 21, 2003 at 07:52:21AM +1100, Robert Collins wrote: > On Mon, 2003-11-17 at 23:02, Corinna Vinschen wrote: > > > > And, structures like > > > the FindNext* details change in definition when UNICODE is defined. I > > > was trying to avoid all that complexity, which is significant, by > > > staying in a thunk approach. > > > > Yep, I agree, that's an extra problem. But it doesn't invalidate the > > general idea of putting the work into autoload and path_conv. The > > FindFile example might be something which justifies the use of wrapper > > functions for these very cases. > > Ok. Well for now, I'm going to leave the thunks in place, until / if > they become nothing more than if (unicode) ...W() else A(). That said, > all the calls we are thunking require kernel mode transitions, so I > really don't believe that the thunking will add any overhead on it's > own: the context switch going into kernel will obliterate the much > smaller overhead of checking which call we want to make.
I don't think so. You can't take the kernel into account, really, since it spends its time either case. Anyway, *sic* I don't like the thunking. It's fairly intrusive to the code. It adds another complexity level to a lot of functions which seems pretty unnecessary. It also adds a lot of decisions which are made on runtime over and over again, even though actually it would be sufficient from a logical level to make this decision once. Or at least only once per Win32 function call. Btw., what does "thunk" mean literally? While I know its meaning in the software context, I can't find a simple translation. I looked up three dictionaries to no avail. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developer mailto:[EMAIL PROTECTED] Red Hat, Inc.
