Modified program by creating threads resumed (not suspended),
then using new loop to start each one.
Though new loop completes, and threads are created (31 inclucing
process),
they refuse to be terminated. It seems that RESUME, at least from
another thread, if faulty.
As well, CPU utilizatio
> > > doesn't accept
> > > sleeps smaller than 10ms.
> >
> > That is not true. This program takes half a second on my machine:
>
> This only happens because you are getting a very big time period on
> your test. Sleep, nanosleep and all other timing procedures are simply
> *not* reliable when you
Tests where with app that monitors to at least mS intervals.
Results are consistent with past runs. Altering internal fixed delays
of +/- 1 mS reported acceptable results.
On Oct 11, 2005, at 8:44, Jonas Maebe wrote:
On 11 okt 2005, at 14:39, Paul Davidson wrote:
Tested some sleep and nano
On 11 okt 2005, at 14:39, Paul Davidson wrote:
Tested some sleep and nano sleep functions.
They seems to work well, given the limits of Darwin OS.
Not sure what limits you mean. Darwin has one of the smallest
scheduling latencies of all non-real time OS'es out there. Try
running "sudo lat
Tested some sleep and nano sleep functions.
They seems to work well, given the limits of Darwin OS.
Now tracking possible suspend/resume issues.
On Oct 11, 2005, at 8:35, Jonas Maebe wrote:
On 11 okt 2005, at 14:25, Felipe Monteiro de Carvalho wrote:
The sleep was changed from select to nan
On 11 okt 2005, at 14:25, Felipe Monteiro de Carvalho wrote:
The sleep was changed from select to nanosleep. It seems OS X
doesn't accept
sleeps smaller than 10ms.
That is not true. This program takes half a second on my machine:
This only happens because you are getting a very big time per
> Last couple update to fpc 2.1.1 for Darwin have been broken
>
> Here are some symptom:
>
> At times XCode debugger stops program/trace with SIGSEGV
This is a known issue, the debuginfo is broken. I'm busy with fixing this,
but i don't have much time.
__
On 10/11/05, Jonas Maebe <[EMAIL PROTECTED]> wrote:
> On 11 okt 2005, at 13:46, Marco van de Voort wrote:
> > The sleep was changed from select to nanosleep. It seems OS X
> > doesn't accept
> > sleeps smaller than 10ms.
>
> That is not true. This program takes half a second on my machine:
This on
On Oct 11, 2005, at 7:18, Jonas Maebe wrote:
TThread creation seems about 10 times faster.
Don't know what changed here.
Looking at RTL, Threads are now using semaphores instead of pipes for
suspend/resume.
This may be reason for increased speed.
Jonas
Lets wait for debug to return before making any changes.
Will investigate further at that time
On Oct 11, 2005, at 7:46, Marco van de Voort wrote:
On 11 okt 2005, at 13:11, Paul Davidson wrote:
Don't know what changed here.
The sleep was changed from select to nanosleep. It seems OS X doesn'
> On 11 okt 2005, at 13:46, Marco van de Voort wrote:
>
> > The sleep was changed from select to nanosleep. It seems OS X
> > doesn't accept
> > sleeps smaller than 10ms.
>
> That is not true. This program takes half a second on my machine:
Odd then. There was a problem with threadshutdown tha
On 11 okt 2005, at 13:46, Marco van de Voort wrote:
The sleep was changed from select to nanosleep. It seems OS X
doesn't accept
sleeps smaller than 10ms.
That is not true. This program takes half a second on my machine:
#include
int main() {
struct timespec t1;
int i;
t1.tv_sec =
> On 11 okt 2005, at 13:11, Paul Davidson wrote:
>
> Don't know what changed here.
The sleep was changed from select to nanosleep. It seems OS X doesn't accept
sleeps smaller than 10ms. Maybe revert to select() for Mac OS X only?
(the select breaks Kylix compat on Linux)
On 11 okt 2005, at 13:11, Paul Davidson wrote:
Last couple update to fpc 2.1.1 for Darwin have been broken
Here are some symptom:
At times XCode debugger stops program/trace with SIGSEGV
Debugging info in 2.1.1 is currently broken on all platforms.
TThread creation seems about 10 times fa
14 matches
Mail list logo
