Overlapped calls and lastError functions

Blair,

Dumb question: Suppose a Process makes a mix of overlapped and standard
function calls.  What currently happens to TLS things like GetLastError()?

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Bill Schwab" <[hidden email]> wrote in message
news:bn4cji$se29p$[hidden email]...
> Blair,
>
> Dumb question: Suppose a Process makes a mix of overlapped and standard
> function calls.  What currently happens to TLS things like GetLastError()?

There is no general solution (one of the motivations behind the long
standing enhancement #131 "Allow a process to establish an affinity with a
particular overlapped call thread"), however the CRT errno and Win32
GetLastError() code are cached on completion of an overlapped call in the
'errno' and 'lastError' instance variables of the Process that initiated the
call. See the Process>>errno and Process>>lastError methods.

Regards

Blair

Blair,

> > Dumb question: Suppose a Process makes a mix of overlapped and standard
> > function calls.  What currently happens to TLS things like
GetLastError()?
>
> There is no general solution (one of the motivations behind the long
> standing enhancement #131 "Allow a process to establish an affinity with a
> particular overlapped call thread"), however the CRT errno and Win32
> GetLastError() code are cached on completion of an overlapped call in the
> 'errno' and 'lastError' instance variables of the Process that initiated
the
> call. See the Process>>errno and Process>>lastError methods.

Thanks for the pointer.  However, I'm dealing with OpenSSL, which has a
rather "elaborate" error reporting system, which must be called on the same
thread as the failed function.  It sounds like it might be necessary to
write another DLL that wraps the troublesome functions, grabs/decode error
information during the overlapped call, and stuffs it in buffers provided by
the caller.  Does that sound like it should work?

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill

You wrote in message news:bn6g43$rqi2d$[hidden email]...
>...
> > call. See the Process>>errno and Process>>lastError methods.
>
> Thanks for the pointer.  However, I'm dealing with OpenSSL, which has a
> rather "elaborate" error reporting system, which must be called on the
same
> thread as the failed function.  It sounds like it might be necessary to
> write another DLL that wraps the troublesome functions, grabs/decode error
> information during the overlapped call, and stuffs it in buffers provided
by
> the caller.  Does that sound like it should work?

I can't think of any reason why not.

Regards

Blair

Blair,

> > Thanks for the pointer.  However, I'm dealing with OpenSSL, which has a
> > rather "elaborate" error reporting system, which must be called on the
> same
> > thread as the failed function.  It sounds like it might be necessary to
> > write another DLL that wraps the troublesome functions, grabs/decode
error
> > information during the overlapped call, and stuffs it in buffers
provided
> by
> > the caller.  Does that sound like it should work?
>
> I can't think of any reason why not.

Wild pointers, buffer overruns, non-initialized memory, too many free()
calls, etc. :)

Satire aside, do you agree that it's probably the only solution?  Assuming
for the moment that the answer is yes, am I correct in thinking that it
would be safer to pass up an import library in favor of loading the two
OpenSSL DLLs and looking up the desired functions by name?  I once tracked a
_really_ ugly bug back to an out of date import library, and never quite
forgot the experience.  In fairness, that was in the 16 bit Windows days, so
maybe it's no longer as much of a problem??

Another potential factor in import library vs. lookup is that I'm switching
to MinGW where possible.  If Apache would build under it, I'd probably be
completely converted by now.  I think I'm going to be the one building my
OpenSSL libraries, but I can't always be certain which compiler will do the
job, and one never knows when some other product will begin to use OpenSSL,
possibly overwriting my binaries and changing versions and compiler vendors
in the process.  Ideally, I'd like the wrapper DLL to work regardless of
such forces.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill

You wrote in message news:bn77vi$tgl2f$[hidden email]...
> ...
> > > Thanks for the pointer.  However, I'm dealing with OpenSSL, which has
a
> > > rather "elaborate" error reporting system, which must be called on the
> > same
> > > thread as the failed function.  It sounds like it might be necessary
to
Well, those could very well exist in the OpenSSL code anyway, so you'll be
in good company.

The layer ought to be pretty thin & simple too.

> Satire aside, do you agree that it's probably the only solution?

Yes, I think so, unless there are other pre-built third-party wrappers (e.g.
an Active-X component). However I have found that the design and
implementation quality of these can often be suspect.

>...Assuming
> for the moment that the answer is yes, am I correct in thinking that it
> would be safer to pass up an import library in favor of loading the two
> OpenSSL DLLs and looking up the desired functions by name?  I once tracked
a
> _really_ ugly bug back to an out of date import library, and never quite
> forgot the experience.  In fairness, that was in the 16 bit Windows days,
so
> maybe it's no longer as much of a problem??

I would always use an implib by preference - its easier, less prone to
error, and means that tools such as Depends.exe will work correctly. There
is hardly ever a need to use GetProcAddress() in a C program, especially now
that delayed loading of DLLs is supported. Of course the Dolphin VM does it
to support an interactive programming environment that allows one to add new
libraries and function calls at will, but it uses normal DLL linking for its
own purposes.

> Another potential factor in import library vs. lookup is that I'm
switching
> to MinGW where possible.  If Apache would build under it, I'd probably be
> completely converted by now.  I think I'm going to be the one building my
> OpenSSL libraries, but I can't always be certain which compiler will do
the
> job, and one never knows when some other product will begin to use
OpenSSL,
> possibly overwriting my binaries and changing versions and compiler
vendors
> in the process.  Ideally, I'd like the wrapper DLL to work regardless of
> such forces.

I'm afraid I can't help you there.

Regards

Blair

Blair,

> > Wild pointers, buffer overruns, non-initialized memory, too many free()
> > calls, etc. :)
> > ...
>
> Well, those could very well exist in the OpenSSL code anyway, so you'll be
> in good company.

Actually, I've been slowly realizing that it's pretty good, even if it does
suffer a few creeping complexities.


> The layer ought to be pretty thin & simple too.

So far at least.  I _think_ it's done.


> > Satire aside, do you agree that it's probably the only solution?
>
> Yes, I think so, unless there are other pre-built third-party wrappers
(e.g.
> an Active-X component). However I have found that the design and
> implementation quality of these can often be suspect.

Agreed.  I'd much rather have a home-grown DLL.  For the error messages, I
briefly considered using IStream and marshaling the pointers across threads,
but a one-time/reused memory buffer (one per connection) takes care of it
with less risk.


> I would always use an implib by preference - its easier,

And that's why I decided to use one.  If the whole mess actually works, then
I might consider changing it dynamic lookup. Here's hoping it's a big enough
success to have trouble with ordinals.


Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]