[fpc-pascal] teventobject.create fails with error 161

[Snorkl e]

Hi Tomas,

TEventobject.create is the only thing called in the thread constructor, and
teventobject.create is indeed calling a API function in order to create the
event.  There is no other way to find out if teventobject.create failed as
teventobject.handle always has a value even if it fails.
So what I am getting at is its extremely likely getlasterror applies even
though it does not call  winapi directly.

Since I solved it by giving the name param a giud, the next thing to ask is
why does teventobject fail kind of silently when the name parm is blank
over time?

Also keep in mind this is third party code, so I don't really know why they
used teventobject as much as they did, I would imagine they didn't want to
use critical sections all over the place.

And yes the event object does get destroyed when the thread finishes.
I understand what your saying about the differences between getlasterror
and getlastoserror.

I do appreciate the comments :-)

On Oct 14, 2016 12:28 PM, "Tomas Hajny" <XHajT03 at hajny.biz> wrote:

> On Fri, October 14, 2016 17:44, Snorkl e wrote:
>
>
> Hi,
>
> > Hi, actually getlasterror only applies to the calling thread,
> > getlastOSerror is the one not to use.
> > Anyway I think I found the solution.
>  .
>  .
>
> I'm glad that you found potential reason of the problem, but your
> assumption regarding GetLastError and GetLastOSError is not entirely
> correct. You're right that GetLastError returns the last error in the
> current thread, because that is written in the respective MSDN
> documentation. I don't think that this is in contradiction to the
> information from Jonas though.
>
> Moreover, the only difference between GetLastError and GetLastOSError is
> the fact that GetLastError is direct part of the MS Windows API (and thus
> it behaves exactly as described in MSDN, but it is platform-specific),
> whereas GetLastOSError is the FPC RTL abstraction for returning error
> information from the underlying operating system (available across
> different platforms). As such, you should rely on the behaviour of
> GetLastOSError only to the level documented in the FPC documentation (in
> other words, certain aspects described in MSDN documentation for
> GetLastError may not be valid for GetLastOSError on all FPC supported
> platforms due to differences in error handling on different platforms).
>
> As an example, direct calls to Windows API bypassing FPC RTL and resulting
> in an error would change the value returned by GetLastOSError on MS
> Windows, whereas direct calls to OS/2 API bypassing FPC RTL and resulting
> in an error would _not_ change the value returned by GetLastOSError on
> OS/2.
>
> The implementation of GetLastOSError for MS Windows (Win32 or Win64)
> consists of a direct call to GetLastError and thus the same caveats apply
> for them on that platform.
>
> Tomas
>
>
> >
> > On Oct 14, 2016 9:23 AM, "Jonas Maebe" <jonas.maebe at elis.ugent.be>
> wrote:
> >
> >> On 14/10/16 02:43, Snorkl e wrote:
> >>
> >>> Anyway, I am using a third party SFTP server lib and it creates a
> >>> thread
> >>> inherited from tthread and in the create event of the tthread
> >>> descendant
> >>> it does this:
> >>> (It uses this thread to read and write data on the socket)
> >>>
> >>> FDataAvailable := TEvent.Create(nil, True, False, '');  //tevent maps
> >>> to
> >>> teventobject
> >>>
> >>> {$IFDEF MSWINDOWS}
> >>>   lasterr:=GetLastError;
> >>>
> >>
> >> GetLastError() will return the error code of the last Windows API call
> >> that has been performed. I doubt TEvent.Create() guarantees not to call
> >> any
> >> Windows API's between creating an event using a Windows event and
> >> returning. E.g., it might allocate or free memory in between, or the FPC
> >> RTL may have done that in the context of handling the constructor call.
> >>
> >> You should only call GetLastError() immediately after calling a Windows
> >> API function yourself. In any other case, you cannot know what may have
> >> transpired in between.
> >>
> >>
> >> Jonas
>
>
> _______________________________________________
> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20161014/197e5209/attachment.html>