Re: [Lazarus] lazarus for visually impaired user
On 25 October 2017 at 03:48, Mgr. Janusz Chmiel via Lazarus < lazarus@lists.lazarus-ide.org> wrote: > Who of us would initiate crout founding campaign by using Indigo or other > servers, so Lazarus would become fully accessible. While not putting my hand up to be involved (too busy I'm afraid), I would happily contribute financially to this or similar endeavor. Right - back to lurking... Mike -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Weird object variables access [SOLVED] - Delphi mode bug!
On Tue, 24 Oct 2017, Giuliano Colla wrote: Il 24/10/2017 14:10, Michael Van Canneyt via Lazarus ha scritto: A valid method can never be stored in a pointer, since the former is actually 2 pointers (method/data) and the latter is just 1 pointer. That the assignment is valid is Delphi compatible: only the procedure address is copied. I can confirm it as an fpc bug. No, I'm sorry to say that IMO you did not. I looked at your code. It simply works by accident in Delphi, because you are calling a method of the same object as the caller. Try calling a method of another object, and displaying the classname and make sure you trash the registers between the assignment of the method pointer and actually calling it. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] lazarus for visually impaired user
Dear specialists, Because making Lazarus accessible for visually impaired future developers is so easy, that it is rather not realistic, that somebody will make it free of charge, since project development is very heavy even without making it accessible for screen readers users, I have other constructive suggestion. Who of us would initiate crout founding campaign by using Indigo or other servers, so Lazarus would become fully accessible. Please take in mind, that even latest Embarcade products are not fully accessible. The goal of The project would make Lazarus IDE fully accessible including form designer and also all libraries or units, which this IDE uses to make accessible also other packages, such Lamw, Lazarus android module wizard. Any opinions will be very welcomed. It would be great, since it would allow visually impaired programmers to develop professionally looked apps without need to use sighted assistance. May be, that The manager of The whole project would try to think about it. Since finance from such campaign would be divided between engaged developers. I Am afraid, that The best results can only be achieved, if advanced Pascal developers, who are intensively developing Lazarus for several years can achieve this goal. I think it well. I know, that making such thinks, thinks, which have not been made even by big commercial companies can not be made by yours team free of charge thanks its complexity. I believe, that somebody will atleast think about my suggestion. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Weird object variables access [SOLVED] - Delphi mode bug!
On 24.10.2017 19:00, Giuliano Colla via Lazarus wrote: > Il 24/10/2017 17:04, Sven Barth via Lazarus ha scritto: >> >> @NextProc := Coda.Remove; >> Sending := True; >> NextProc; >> >> with NextProc defined as a procedure of object does compile but >> it's wrong. >> >> >> Why are you using an @ when you assign the NextProc variable? O.o >> > Because it's required by Delphi syntax. An unqualified procedural type > means a call to the procedure. > > Without the @ it would rise an "invalid left hand assignment" error. You're completely defeating the type system here and at least in Delphi XE the value of Self is Nil if I do it like you did above. If it indeed worked in older versions then it probably worked completely by accident. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Weird object variables access [SOLVED] - Delphi mode bug!
Il 24/10/2017 17:04, Sven Barth via Lazarus ha scritto: @NextProc := Coda.Remove; Sending := True; NextProc; with NextProc defined as a procedure of object does compile but it's wrong. Why are you using an @ when you assign the NextProc variable? O.o Because it's required by Delphi syntax. An unqualified procedural type means a call to the procedure. Without the @ it would rise an "invalid left hand assignment" error. Giuliano -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Weird object variables access [SOLVED] - Delphi mode bug!
Am 24.10.2017 14:57 schrieb "Giuliano Colla via Lazarus" < lazarus@lists.lazarus-ide.org>: Il 24/10/2017 14:15, Mattias Gaertner via Lazarus ha scritto: > On Tue, 24 Oct 2017 13:56:43 +0200 > Giuliano Colla via Lazarus wrote: > > > [...] >> >> Now the catch is that the queue used is just a queue of pointers, while >> here we're dealing with procedures of object. This is legal with Delphi >> syntax, while it is forbidden in ObjFpc. >> > It's only legal with a typecast. > You can typecast a procedure of object to a pointer, but not the opposite. And that is good. > When I tried to see if the >> problem was originated by Delphi mode, and changed to objfpc mode, it >> turned out that there was no way to make it compile. >> > The compiler tried to protect you from shooting yourself in the foot. > > Yes, but not in Delphi mode. But just changing >> my queue from a queue of pointers to a queue of TProc (TProc = procedure >> of object) fixes the issue: it compiles, it works, Self is correct, >> there's no need to qualify the identifier, and all is well. >> >> The moral of the story is: in Delphi mode you can assign a procedure of >> object to a pointer, and the compiler doesn't complain, but it is wrong, >> > I just tried with $mode delphi: > > p:=o.DoIt; > > test1.pas(32,4) Error: Invalid assignment, procedures return no > value > But in Delphi mode @NextProc := Coda.Remove; Sending := True; NextProc; with NextProc defined as a procedure of object does compile but it's wrong. Why are you using an @ when you assign the NextProc variable? O.o Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Request for merge to 1.8
OK. Thank you for responce. -- FTurtle -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Weird object variables access [SOLVED] - Delphi mode bug!
Il 24/10/2017 14:15, Mattias Gaertner via Lazarus ha scritto: On Tue, 24 Oct 2017 13:56:43 +0200 Giuliano Colla via Lazarus wrote: [...] Now the catch is that the queue used is just a queue of pointers, while here we're dealing with procedures of object. This is legal with Delphi syntax, while it is forbidden in ObjFpc. It's only legal with a typecast. You can typecast a procedure of object to a pointer, but not the opposite. And that is good. When I tried to see if the problem was originated by Delphi mode, and changed to objfpc mode, it turned out that there was no way to make it compile. The compiler tried to protect you from shooting yourself in the foot. Yes, but not in Delphi mode. But just changing my queue from a queue of pointers to a queue of TProc (TProc = procedure of object) fixes the issue: it compiles, it works, Self is correct, there's no need to qualify the identifier, and all is well. The moral of the story is: in Delphi mode you can assign a procedure of object to a pointer, and the compiler doesn't complain, but it is wrong, I just tried with $mode delphi: p:=o.DoIt; test1.pas(32,4) Error: Invalid assignment, procedures return no value But in Delphi mode @NextProc := Coda.Remove; Sending := True; NextProc; with NextProc defined as a procedure of object does compile but it's wrong. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Weird object variables access [SOLVED] - Delphi mode bug!
Il 24/10/2017 14:10, Michael Van Canneyt via Lazarus ha scritto: A valid method can never be stored in a pointer, since the former is actually 2 pointers (method/data) and the latter is just 1 pointer. That the assignment is valid is Delphi compatible: only the procedure address is copied. I wonder if Delphi does such a stupid thing, or rather it stores in the pointer the address of a pointer pair (method/data). However here the issue is that a pointer can be assigned to a "procedure of object" without flagging an error: type TProc = Procedure of object; .. NextProc: TProc; @NextProc := Coda.Remove; // Remove returns a pointer Sending := True; NextProc; This compiles (in Delphi mode) without generating an error, and it is wrong, because NextProc is a Method, not a simple procedure. Giuliano -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Weird object variables access - fpc issue?
On 24/10/17 12:59, Mattias Gaertner via Lazarus wrote: > ASystemTime is a stack variable. That's thread-safe. > > In fpc trunk it calls GetLocalTime on Unix, which fetches timezone > every time. No global var. So it should be thread safe. > >> because each thread instance would have its own local variables, right? >> so no thread would step on each others' toes; > > You have to check called code too. > > Mattias > On 24/10/17 13:06, Sven Barth via Lazarus wrote: > > ASystemTime is a local variable, so two threads won't influence each other > there thus at least on Windows Now() is threadsafe. > > Regards, > Sven > > MMMmmm... i can't exactly now but I will try to reproduce what I was seeing ... for now sorry for the noise... el es -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Weird object variables access [SOLVED] - Delphi mode bug!
On Tue, 24 Oct 2017 13:56:43 +0200 Giuliano Colla via Lazarus wrote: >[...] > Yes, you're right, that's what clarifies the issue. When it works, Self > is a TFORM1 object, when it fails, Self is just Nil. > > But now it's also clear why this happens. I'm glad you figured it out. >[...] > Now the catch is that the queue used is just a queue of pointers, while > here we're dealing with procedures of object. This is legal with Delphi > syntax, while it is forbidden in ObjFpc. It's only legal with a typecast. > When I tried to see if the > problem was originated by Delphi mode, and changed to objfpc mode, it > turned out that there was no way to make it compile. The compiler tried to protect you from shooting yourself in the foot. > But just changing > my queue from a queue of pointers to a queue of TProc (TProc = procedure > of object) fixes the issue: it compiles, it works, Self is correct, > there's no need to qualify the identifier, and all is well. > > The moral of the story is: in Delphi mode you can assign a procedure of > object to a pointer, and the compiler doesn't complain, but it is wrong, I just tried with $mode delphi: p:=o.DoIt; test1.pas(32,4) Error: Invalid assignment, procedures return no value Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Weird object variables access [SOLVED] - Delphi mode bug!
On Tue, 24 Oct 2017, Giuliano Colla via Lazarus wrote: Il 23/10/2017 22:57, Mattias Gaertner via Lazarus ha scritto: Check if 'Self' inside SendMessage is the right instance. The moral of the story is: in Delphi mode you can assign a procedure of object to a pointer, and the compiler doesn't complain, but it is wrong, because when you call your method through this pointer, the method is executed, but it's unaware of the data space of the object it belongs to, even if it's called from another method of the same object! If the method doesn't access variables of the object, everything appears to work, but if it does the program simply crashes. I will try to see if the same occurs also in Delphi, to understand if it's a Delphi bug or an fpc bug. A valid method can never be stored in a pointer, since the former is actually 2 pointers (method/data) and the latter is just 1 pointer. That the assignment is valid is Delphi compatible: only the procedure address is copied. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Weird object variables access - fpc issue?
Am 24.10.2017 13:41 schrieb "el es via Lazarus" < lazarus@lists.lazarus-ide.org>: On 24/10/17 10:04, Mattias Gaertner via Lazarus wrote: > On Tue, 24 Oct 2017 08:59:36 +0100 > el es via Lazarus wrote: > >> On 23/10/17 20:00, Giuliano Colla via Lazarus wrote: >> [snip] >> >> I don't remember if I was hitting AV using Now(), likely I wasn't - >> but due to 'normal' Now() being not thread safe, I was getting inconsistent >> timing results, when I used Now() both in main thread and in the thread; > > AFAIK Now is thread safe. On what platform and how did you test? > > Mattias > Now() is literally function Now : TDateTime; var ASystemTime : TSYSTEMTIME; begin GetSystemTime(ASystemTime); Result := SystemTimeToDateTime(ASystemTime); end; on my installation (lazarus 1.6.4 #54278, FPC 3.0.2) I'd say it's questionable to say it's thread-safe that way; It may be safe to use in main thread (where no 2 different contexts can mangle each others ASystemTime); ASystemTime is a local variable, so two threads won't influence each other there thus at least on Windows Now() is threadsafe. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Weird object variables access - fpc issue?
On Tue, 24 Oct 2017 12:41:11 +0100 el es via Lazarus wrote: >[...] > Now() is literally > > function Now : TDateTime; > var ASystemTime : TSYSTEMTIME; > begin >GetSystemTime(ASystemTime); >Result := SystemTimeToDateTime(ASystemTime); > end; > > on my installation (lazarus 1.6.4 #54278, FPC 3.0.2) > > I'd say it's questionable to say it's thread-safe that way; It may be safe to > use in > main thread (where no 2 different contexts can mangle each others > ASystemTime); ASystemTime is a stack variable. That's thread-safe. In fpc trunk it calls GetLocalTime on Unix, which fetches timezone every time. No global var. So it should be thread safe. > because each thread instance would have its own local variables, right? > so no thread would step on each others' toes; You have to check called code too. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Weird object variables access [SOLVED] - Delphi mode bug!
Il 23/10/2017 22:57, Mattias Gaertner via Lazarus ha scritto: Check if 'Self' inside SendMessage is the right instance. Yes, you're right, that's what clarifies the issue. When it works, Self is a TFORM1 object, when it fails, Self is just Nil. But now it's also clear why this happens. The issue has nothing to do with thread code, it has to do with Delphi mode and Delphi syntax! It is either an fpc Delphi mode bug, or a Delphi bug, kept in fpc for "compatibility". The full story is that this application has been originally written more than 20 years ago, using Delphi 3. Then it was updated to Delphi 5, and subsequently ported to Lazarus, but keeping the Delphi mode, to minimize the changes. SendMessage can be called in two ways: either directly from another main thread method, or somehow indirectly (always from another main thread method), through a NextProc value fetched from a queue. The application is used to upload a program to an embedded processor. The main thread reads by chunks from the disk the program to be uploaded and pushes into a queue what should be done next (send the first header, send an intermediate chunk, send the last chunk, send the program version and date, etc). At the good time, the appropriate method is fetched from the queue and called; in turn it calls SendMessage to do the actual job. When SendMessage is called directly from another method, the Self instance is correct, when it is called indirectly by a fetching from the queue the method to call, Self is just Nil. Now the catch is that the queue used is just a queue of pointers, while here we're dealing with procedures of object. This is legal with Delphi syntax, while it is forbidden in ObjFpc. When I tried to see if the problem was originated by Delphi mode, and changed to objfpc mode, it turned out that there was no way to make it compile. But just changing my queue from a queue of pointers to a queue of TProc (TProc = procedure of object) fixes the issue: it compiles, it works, Self is correct, there's no need to qualify the identifier, and all is well. The moral of the story is: in Delphi mode you can assign a procedure of object to a pointer, and the compiler doesn't complain, but it is wrong, because when you call your method through this pointer, the method is executed, but it's unaware of the data space of the object it belongs to, even if it's called from another method of the same object! If the method doesn't access variables of the object, everything appears to work, but if it does the program simply crashes. I will try to see if the same occurs also in Delphi, to understand if it's a Delphi bug or an fpc bug. Giuliano -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Weird object variables access - fpc issue?
On 24/10/17 10:04, Mattias Gaertner via Lazarus wrote: > On Tue, 24 Oct 2017 08:59:36 +0100 > el es via Lazarus wrote: > >> On 23/10/17 20:00, Giuliano Colla via Lazarus wrote: >> [snip] >> >> I don't remember if I was hitting AV using Now(), likely I wasn't - >> but due to 'normal' Now() being not thread safe, I was getting inconsistent >> timing results, when I used Now() both in main thread and in the thread; > > AFAIK Now is thread safe. On what platform and how did you test? > > Mattias > Now() is literally function Now : TDateTime; var ASystemTime : TSYSTEMTIME; begin GetSystemTime(ASystemTime); Result := SystemTimeToDateTime(ASystemTime); end; on my installation (lazarus 1.6.4 #54278, FPC 3.0.2) I'd say it's questionable to say it's thread-safe that way; It may be safe to use in main thread (where no 2 different contexts can mangle each others ASystemTime); But I had problems using Now() in main thread context (graphic) and in additional thread(s) _simultaneously_. I do not recall getting AV's, but I was getting mangled results when calls to Now() overlapped from 2 different thread contexts. (try it by calling Now() from a TTimer.OnTimer handler, simultaneously with a background thread also calling Now() in a loop.) I guess, simpler code for ThreadNow would be 'just' thread-local/nested to Execute() function containing just a pair of GetSystemTime(ASystemTime); Result := SystemTimeToDateTime(ASystemTime); (or literally a copy of Now(); ) because each thread instance would have its own local variables, right? so no thread would step on each others' toes; Hopefully this makes sense now ;) el es -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Weird object variables access - fpc issue?
On 24/10/17 10:20, Michael Schnell via Lazarus wrote: > On 24.10.2017 10:48, el es via Lazarus wrote: >> [...] begin repeat until not ThreadNowInUse; // try ThreadNowInUse :=true; >>> > Busy wait actions are usually a very bad idea > > Better use a TTimer for such. > > -Michael > I suppose you'd need to look at the parent/my post, where it's in full code what this function does ;) tl/dr: it's a function that tries to get a time stamp in (maybe less) thread-safe / (I'd rather call it) reentrant way for use in thread timing and profiling. So no, TTimer not appropriate here. :) el es -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Weird object variables access - fpc issue?
On Tue, 24 Oct 2017, Mattias Gaertner via Lazarus wrote: On Tue, 24 Oct 2017 11:11:15 +0200 (CEST) Michael Van Canneyt via Lazarus wrote: [...] From memory: The first call to Now is not necessarily thread-safe, because of the initialization of TZ info ? Please add this to the docs. After I've verified that my memory in this correct in this matter :) I know that there is some late TZ initialization, but I'm not 100% sure whether Now() invokes it. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Weird object variables access - fpc issue?
On Tue, 24 Oct 2017 11:11:15 +0200 (CEST) Michael Van Canneyt via Lazarus wrote: >[...] > From memory: > The first call to Now is not necessarily thread-safe, because of the > initialization of TZ info ? Please add this to the docs. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Weird object variables access - fpc issue?
On 24.10.2017 11:29, Mattias Gaertner via Lazarus wrote: Are you kidding? If this is not appropriate, I suppose the general design of that functionality should be reconsidered, doing anything that needs a fast reaction in the worker thread. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Weird object variables access - fpc issue?
On Tue, 24 Oct 2017 11:20:50 +0200 Michael Schnell via Lazarus wrote: > On 24.10.2017 10:48, el es via Lazarus wrote: > > [...] > >>> begin > >>>repeat > >>>until not ThreadNowInUse; // > >>> > >>>try > >>> ThreadNowInUse :=true; > >> >[...] > Better use a TTimer for such. Are you kidding? Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Request for merge to 1.8
Sorry FTurtle but I would rather keep this change in trunk only. People may have different opinions about the order. This is a typical change that must happen in the development version and not be pushed to the release at last minute. Besides, you as a semi-developer of Lazarus will use mostly trunk I guess. Juha -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Weird object variables access - fpc issue?
On 24.10.2017 10:48, el es via Lazarus wrote: [...] begin repeat until not ThreadNowInUse; // try ThreadNowInUse :=true; Busy wait actions are usually a very bad idea Better use a TTimer for such. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Weird object variables access - fpc issue?
On Tue, 24 Oct 2017, Mattias Gaertner via Lazarus wrote: On Tue, 24 Oct 2017 08:59:36 +0100 el es via Lazarus wrote: On 23/10/17 20:00, Giuliano Colla via Lazarus wrote: [snip] I don't remember if I was hitting AV using Now(), likely I wasn't - but due to 'normal' Now() being not thread safe, I was getting inconsistent timing results, when I used Now() both in main thread and in the thread; AFAIK Now is thread safe. On what platform and how did you test? From memory: The first call to Now is not necessarily thread-safe, because of the initialization of TZ info ? Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Weird object variables access - fpc issue?
On Tue, 24 Oct 2017 08:59:36 +0100 el es via Lazarus wrote: > On 23/10/17 20:00, Giuliano Colla via Lazarus wrote: > [snip] > > I don't remember if I was hitting AV using Now(), likely I wasn't - > but due to 'normal' Now() being not thread safe, I was getting inconsistent > timing results, when I used Now() both in main thread and in the thread; AFAIK Now is thread safe. On what platform and how did you test? Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Weird object variables access - fpc issue?
Am 24.10.2017 10:49 schrieb "el es via Lazarus" < lazarus@lists.lazarus-ide.org>: On 24/10/17 09:11, Mattias Gaertner via Lazarus wrote: > On Tue, 24 Oct 2017 08:59:36 +0100 > el es via Lazarus wrote: > >> [...] >> begin >> repeat >> until not ThreadNowInUse; // >> >> try >> ThreadNowInUse :=true; > > This is not thread safe. > > Mattias > Because separated by 'try' ? I see; Will it be enough to put it like try repeat until not ThreadNowInUse; ThreadNowInUse := true; ... ? You should look at InterlockedCompareExchange(), everything else is an accident waiting to happen (except for a critical section, but that would be overkill on the other hand). Regards, Sven I haven't ran into problems with my routine yet, but I wasn't really calling it in a very 'tight loop' (as it is used for timing/'profiling' the calls to hardware 'master node' routines and for deciding whether the thread should go to sleep; so there is always ample time between calls to ThreadNow() and it's only called in context of the thread; so the 'poor mans semaphore' isn't really that required - it's just a safeguard) (probably if I need timing measurements, every other type of thread I will ever define, will have their own ThreadNow call) I realize I could just use 'naked' GetSystemTime + SystemTimeToDateTime pair with a local variable; or define the above pair as a nested function in the thread, that'll serialize it enough... Anyone ever thought of a thread-safe global Now() call ? el es -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Weird object variables access - fpc issue?
On 24/10/17 09:11, Mattias Gaertner via Lazarus wrote: > On Tue, 24 Oct 2017 08:59:36 +0100 > el es via Lazarus wrote: > >> [...] >> begin >> repeat >> until not ThreadNowInUse; // >> >> try >> ThreadNowInUse :=true; > > This is not thread safe. > > Mattias > Because separated by 'try' ? I see; Will it be enough to put it like try repeat until not ThreadNowInUse; ThreadNowInUse := true; ... ? I haven't ran into problems with my routine yet, but I wasn't really calling it in a very 'tight loop' (as it is used for timing/'profiling' the calls to hardware 'master node' routines and for deciding whether the thread should go to sleep; so there is always ample time between calls to ThreadNow() and it's only called in context of the thread; so the 'poor mans semaphore' isn't really that required - it's just a safeguard) (probably if I need timing measurements, every other type of thread I will ever define, will have their own ThreadNow call) I realize I could just use 'naked' GetSystemTime + SystemTimeToDateTime pair with a local variable; or define the above pair as a nested function in the thread, that'll serialize it enough... Anyone ever thought of a thread-safe global Now() call ? el es -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Weird object variables access - fpc issue?
On Tue, 24 Oct 2017 08:59:36 +0100 el es via Lazarus wrote: >[...] > begin > repeat > until not ThreadNowInUse; // > > try > ThreadNowInUse :=true; This is not thread safe. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Weird object variables access - fpc issue?
On 23/10/17 20:00, Giuliano Colla via Lazarus wrote: [snip] I don't remember if I was hitting AV using Now(), likely I wasn't - but due to 'normal' Now() being not thread safe, I was getting inconsistent timing results, when I used Now() both in main thread and in the thread; So with my application I ended up re-implementing Now() into ThreadNow : var ThreadNowInUse :boolean = false; // unit global 'just' above the function function TMyThread.ThreadNow: TDateTime; var ASystemTime : TSYSTEMTIME; // struct.inc, I'm under Windows begin repeat until not ThreadNowInUse; // try ThreadNowInUse :=true; GetSystemTime(ASystemTime); Result := SystemTimeToDateTime(ASystemTime); finally ThreadNowInUse := false; end; end; Hope this helps el es -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
