Hi, actually getlasterror only applies to the calling thread,
getlastOSerror is the one not to use.
Anyway I think I found the solution.
Just for kicks I put in a name with a / I.e /test_name and getlasterror
came back with the same error.  So the API is being called somewhere with
teventobject.create, anyway instead of leaving name blank I put a giud in
for the name and low and behold the error stopped.  It appears there is a
limit or a bug on creating unnamed events from a single process.   When you
leave name blank the os must be creating a unique name somehow and it has
some issue with a lot of them being created and destroyed. When I compiled
as 64bit it took much longer for the error to happen.  After I used the
guid for the event name I stress tested the server with 10s of thousands of
connection and disconnecting and that error never happened again.

So windows limit or bug? Or could it be a bug in  FPC?

On Oct 14, 2016 9:23 AM, "Jonas Maebe" <jonas.ma...@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@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
_______________________________________________
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Reply via email to