14.12.2018, 13:17, "Martin Frb" : Could "Thread.FFinished := True;" be moved to the top? (potentially together with "Result := Thread.FReturnValue;" so the order of those 2 remains).The reason is, that then (on a suspended thread) it would be save to change "FreeOnTerminate" if "Finished = Fal
On 14/12/18 19:56, Luca Olivetti wrote:
I also read the manual page for pthread_cancel and even when using
pthread_canceltype(PTHREAD_CANCEL_AYNCHRONOUS) "The thread can be
canceled at any time. (Typically, it will be canceled immediately upon
receiving a cancellation request, but the system d
El 14/12/18 a les 18:08, Jonas Maebe ha escrit:
On 14/12/18 11:09, Luca Olivetti wrote:
I think that TThread should have a method to kill it for such cases,
using, e.g., pthread_cancel under unix
pthread_cancel() does not not kill a thread. Conceptually, it is exactly
the same as calling TT
On 14/12/18 11:09, Luca Olivetti wrote:
I think that TThread should have a method to kill it for such cases,
using, e.g., pthread_cancel under unix
pthread_cancel() does not not kill a thread. Conceptually, it is exactly
the same as calling TThread.terminate: it just sets a property for the
On 14/12/2018 10:08, Michael Van Canneyt wrote:
> And now we have come to the root of the problem:
>
> Threads are unpredictable, and hence evil in programming :-)
>
Aye, but the evil is necessary, for example if one has to
a program that needs to do GUI AND handle background communication/pro
Am Fr., 14. Dez. 2018, 11:26 hat Luca Olivetti
geschrieben:
> El 13/12/18 a les 20:36, Martin Frb ha escrit:
>
> > The thread may makes calls (several, one after the other) into a
> > library, and each of those calls may not return for some time (to long
> > for the main thread to wait, without t
Am Fr., 14. Dez. 2018, 11:23 hat Michael Van Canneyt
geschrieben:
>
>
> On Fri, 14 Dec 2018, Sven Barth via fpc-pascal wrote:
>
> > Am Fr., 14. Dez. 2018, 10:31 hat Michael Van Canneyt <
> mich...@freepascal.org>
> > geschrieben:
> >
> >>
> >>
> >> On Fri, 14 Dec 2018, el es wrote:
> >>
> >>> On
El 13/12/18 a les 20:36, Martin Frb ha escrit:
The thread may makes calls (several, one after the other) into a
library, and each of those calls may not return for some time (to long
for the main thread to wait, without the app becoming unresponsive). And
the structure of that library may not
On Fri, 14 Dec 2018, OBones wrote:
Michael Van Canneyt wrote:
I think FreeOnTerminate should not even exist. IMO it should simply
be 'True'.
This is where I strongly disagree, to me it should always be False,
because having things free up themselves at unpredictable times is a
recipe for di
On Fri, 14 Dec 2018, Sven Barth via fpc-pascal wrote:
Am Fr., 14. Dez. 2018, 10:31 hat Michael Van Canneyt
geschrieben:
On Fri, 14 Dec 2018, el es wrote:
On 13/12/2018 22:23, Michael Van Canneyt wrote:
On Thu, 13 Dec 2018, Martin Frb wrote:
Besides, the documentation does not
Michael Van Canneyt wrote:
I think FreeOnTerminate should not even exist. IMO it should simply
be 'True'.
This is where I strongly disagree, to me it should always be False,
because having things free up themselves at unpredictable times is a
recipe for disaster which already hit me badly.
For
On 14/12/2018 10:30, Michael Van Canneyt wrote:
(or as Martin says, it should be documented as such?)
This is a valid point and I intend to elaborate the TThread documentation
somewhat, with this in mind.
I did have an error in my initial example:
t := TThread.create(false); // create no
Am Fr., 14. Dez. 2018, 10:31 hat Michael Van Canneyt
geschrieben:
>
>
> On Fri, 14 Dec 2018, el es wrote:
>
> > On 13/12/2018 22:23, Michael Van Canneyt wrote:
> >>
> >>
> >> On Thu, 13 Dec 2018, Martin Frb wrote:
> >>
> >>>
> >>> Besides, the documentation does not say that FreeOnTerminate
On Fri, 14 Dec 2018, OBones wrote:
Michael Van Canneyt wrote:
On Fri, 14 Dec 2018, el es wrote:
On 13/12/2018 22:23, Michael Van Canneyt wrote:
On Thu, 13 Dec 2018, Martin Frb wrote:
Besides, the documentation does not say that FreeOnTerminate
is limited to be used in the threa
Michael Van Canneyt wrote:
On Fri, 14 Dec 2018, el es wrote:
On 13/12/2018 22:23, Michael Van Canneyt wrote:
On Thu, 13 Dec 2018, Martin Frb wrote:
Besides, the documentation does not say that FreeOnTerminate
is limited to be used in the thread construction. Especially since
its ef
On Fri, 14 Dec 2018, el es wrote:
On 13/12/2018 22:23, Michael Van Canneyt wrote:
On Thu, 13 Dec 2018, Martin Frb wrote:
Besides, the documentation does not say that FreeOnTerminate
is limited to be used in the thread construction. Especially since
its effect is not due until "termi
On 13/12/2018 22:23, Michael Van Canneyt wrote:
>
>
> On Thu, 13 Dec 2018, Martin Frb wrote:
>
>>
>> Besides, the documentation does not say that FreeOnTerminate
>> is limited to be used in the thread construction. Especially since
>> its effect is not due until "terminate"
>
> For me thi
On Thu, 13 Dec 2018, Martin Frb wrote:
Besides, the documentation does not say that FreeOnTerminate is limited
to be used in the thread construction. Especially since its effect is
not due until "terminate"
For me this is a given.
Almost by definition, changing anything in a thread
On 13/12/2018 19:52, Yuriy Sydorov wrote:
On 12/13/2018 1:06 PM, Martin wrote:
Is there a way to use FreeOnTerminate other that setting it in the
constructor (or before the thread starts / or in the rather complex
manner below)?
The doc does not mention any limitations
https://www.freepascal
On 12/13/2018 1:06 PM, Martin wrote:
Is there a way to use FreeOnTerminate other that setting it in the constructor (or before the thread starts / or in the
rather complex manner below)?
The doc does not mention any limitations
https://www.freepascal.org/docs-html/rtl/classes/tthread.freeonter
Is there a way to use FreeOnTerminate other that setting it in the
constructor (or before the thread starts / or in the rather complex
manner below)?
The doc does not mention any limitations
https://www.freepascal.org/docs-html/rtl/classes/tthread.freeonterminate.html
However, setting FreeOn
21 matches
Mail list logo
