thunking, the next step

[Robert Collins]

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 decided against redefining the 'real' calls because I figured some
> > areas may want to use the 'real' calls directly, and only the
> > auto-adjusting parts of cygwin should have the ansi/wide dichotomy.
> 
> I don't know if I understand you right.  I was only talking about
> calls which are affecting the file system.  Other calls like
> CreateSemaphore or what not should still work as before.  The autoload
> part would define some new LoadDLLfuncBLURB which is used only for
> the affected functions.  I (and I assume cgf) was not talking about
> using that approach for all functions with an ascii and a wide char
> implementation.

Never mind, thinko on my part: the A and W versions would still be
directly accesible.

Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://cygwin.com/pipermail/cygwin-patches/attachments/20031120/006e471c/attachment.sig>