On 01/10/2019 20:48, Sven Barth via fpc-pascal wrote:
> Martin mailto:f...@mfriebe.de>> schrieb am Di., 1. Okt.
> 2019, 17:19:
>
> Therefore my question:
> Does RTLeventSetEvent / RTLeventWaitFor make sure memory is
> synchronized
> between threads?
>
> The functions themselves AF
Martin schrieb am Di., 1. Okt. 2019, 17:19:
> I am currently looking at a strange issue in FpDebug.
>
> The main thread loads a lot of data from a file, and creates various
> objects.
>
> Then some code is executed in a sub-thread. The timing of that
> (start/stop of the 2 threads) is handled by
I am currently looking at a strange issue in FpDebug.
The main thread loads a lot of data from a file, and creates various
objects.
Then some code is executed in a sub-thread. The timing of that
(start/stop of the 2 threads) is handled by RTLeventSetEvent /
RTLeventWaitFor.
This code does no
I'm posting here since I cannot add a comment to bug #9836 (probably
because it's closed?)
I'm puzzled because
a) I could find examples of unix daemons, the parent simply exits with exit
b) I swear I saw some fpc example where the parent simply uses halt (or
halt(0)) and most important
c) I'm u
On Friday 22 June 2007 06:27, Carsten Bager wrote:
> In the small threads program below I force a runtime error in a
> thread. How do I get access to the output from the thread when it
> stops? This program does not write anything to the terminal when the
> thread stops.
In case a runtime error oc
In the small threads program below I force a runtime error in a thread.
How do I get access to the output from the thread when it stops?
This program does not write anything to the terminal when the thread stops.
Carsten
---
program testthread
Hi everyone,
I have a program with several thread, I'm having a problem with serial port
due I need to send all the bytes (about 20 bytes/frame)
without delay.
How can I do it?
Can I set priority to thread which is sending byte to serial port to
highest? how?
Can I stop all thread but cur
I have written a small program that uses threads. It works on a 386 Linux,
but I have some problems on the Arm Linux platform.
The program routes a TCP connection to a serial port and if the TCP is not
in use it can route UDP packets to the serial port return answers.
The "sockets.Recv" return
Marco van de Voort wrote:
>> Ok, maybe Sleep(0) in sysutils has to use the sched_yield syscall for
>> linux. This may be a feature request to be reported in bug tracker IMHO.
>
> Ugly. Better define a procedure TryYieldTimeSlice() or so. No need to follow
> Windowisms with archaic reasons.
Yes ag
> > modified demo does in fact make Linux switch between threads. I also
> > tried the Sleep(0) you mentiond in the Sort Demo. Sleep() didn't do
> > the trick, but using the BurnCPU() method from Demo1 did.
>
> Ok, maybe Sleep(0) in sysutils has to use the sched_yield syscall for
> linux. This m
Graeme Geldenhuys wrote:
> pointed out). This sounds like an interesting topic and something
> work understanding. After all, it gave me enough headaches and a
> false positive - thinking it is a bug.
Btw, here is a quote from the interview, default length seems to be
150ms: (it also explains th
Graeme Geldenhuys wrote:
> Ah, finally some explanation that makes sence! Thanks Micha, your
> modified demo does in fact make Linux switch between threads. I also
> tried the Sleep(0) you mentiond in the Sort Demo. Sleep() didn't do
> the trick, but using the BurnCPU() method from Demo1 did.
O
On 29/09/06, Micha Nelissen <[EMAIL PROTECTED]> wrote:
There is no bug. The time slice management is simply different. Try
attached demo (it's your demo modified). You will notice that output
will be mixed.
Linux simply gives longer timeslices to threads (for efficiency reasons).
Micha
Ah, f
Graeme Geldenhuys wrote:
> The Sort Demo, which is a port of the Threads demo included with
> Delphi 7, shows this clearly. I can archive and post the source, but
Try inserting some Sleep(0) to force the kernel to switch to another
thread ? In real worker threads you wouldn't do this of course, b
Graeme Geldenhuys wrote:
> We have a problem!!!
>
> The test project /fcl/tests/threads.pp as well as a Sort Demo (Bubble,
> Section and Quick Sort) all execute the threads in sequence, waiting
> for the previous thread to complete, before the next one executes.
> Kind of defeats the point of usin
So far using FPC 2.0.2 and 2.0.4 and latest Lazarus (svn) it works
fine under Windows. I am now busy building FPC 2.1.1 (svn) under
Windows and will redo the whole process. Will post the result
shortly
Regards,
- Graeme -
On 28/09/06, Vincent Snijders <[EMAIL PROTECTED]> wrote:
Graeme G
The only FPC/Lazarus for windows I have is under the same VMWare
session as I used for Delph 7. And yes it works there, using FPC
2.0.2 with a Lazarus 0.9.15 (9152). I'll be at home in a hour, so
then I can try under FPC 2.1.1 and latest Lazarus.
Regards,
- Graeme -
On 28/09/06, Vincent Snij
Graeme Geldenhuys wrote:
Just to give some more feedback. Using that same Sort App, I compiled
it under Delphi 7, and ran it under Linux using WINE and the threading
worked correctly. So somewhere in FPC or Lazarus lies the problem.
Yeah I know, not very specific. :-)
Can you try running the
Just to give some more feedback. Using that same Sort App, I compiled
it under Delphi 7, and ran it under Linux using WINE and the threading
worked correctly. So somewhere in FPC or Lazarus lies the problem.
Yeah I know, not very specific. :-)
Graeme.
On 28/09/06, Graeme Geldenhuys <[EMAIL P
Attached is the Sort Demo - for incase you have Lazarus.
Graeme.
On 28/09/06, Graeme Geldenhuys <[EMAIL PROTECTED]> wrote:
ok, I see hundreds of a's - press b and quite a bit later I see
hundreds of b's.
Do you have lazarus? I can then post the Sort Demo to show that one as well.
Regards,
ok, I see hundreds of a's - press b and quite a bit later I see
hundreds of b's.
Do you have lazarus? I can then post the Sort Demo to show that one as well.
Regards,
- Graeme -
On 28/09/06, Marco van de Voort <[EMAIL PROTECTED]> wrote:
> The test project /fcl/tests/threads.pp
I see rando
> The test project /fcl/tests/threads.pp
I see random alteration of a and b here.
> The threads.pp test project in fcl, shown a lot of a's on the screen
> and after a while, starts displaying b's on the screen. Looking at
> the source, I gather the a's and b's are supposed to be mixed as each
>
We have a problem!!!
The test project /fcl/tests/threads.pp as well as a Sort Demo (Bubble,
Section and Quick Sort) all execute the threads in sequence, waiting
for the previous thread to complete, before the next one executes.
Kind of defeats the point of using threads.
The Sort Demo, which is
On Oct 28, 2005, at 9:12, Michael Van Canneyt wrote:
On Fri, 28 Oct 2005, Paul Davidson wrote:
Would it be possible to add a property to TThreads to expose
DefaultStackSize in rtl/inc/threadh.inc
Or something similar.
It should be possible, yes, however this will require that the stack
s
On Fri, 28 Oct 2005, Paul Davidson wrote:
Would it be possible to add a property to TThreads to expose DefaultStackSize
in rtl/inc/threadh.inc
Or something similar.
It should be possible, yes, however this will require that the stack
size is added to the constructor: the constructor calls b
Would it be possible to add a property to TThreads to expose
DefaultStackSize in rtl/inc/threadh.inc
Or something similar.
Working on app that uses lots of complex recursion. Ran into problems
and ended rewriting this component. In order to meet stack size limit,
program runs much slower.
26 matches
Mail list logo
