Yes, of course, this still *is* nothing more than an event loop, ...
A decent event loop should use an OS API to free the processor until the
next event is scheduled:
Meta code:
repeat
if (event in event queue) begin // this is either an OS API call or
the event queue is done with user
On Thursday 09 November 2006 08:22, Michael Schnell wrote:
Yes, of course, this still *is* nothing more than an event loop,
...
A decent event loop should use an OS API to free the processor until
the next event is scheduled:
That's why I wrote the example in Esterel.
Give me that API and
Alas, Object Pascal
lacks a decent portable OS tasking interface.
With Delphi we successfully used Windows Messages for inter Thread
communication.
With FPC on Linux a friend of mine used System 5 Messages queues for the
same purpose.
So IMHO inter Thread messages is a good way to go.
On Thu, 9 Nov 2006, Michael Schnell wrote:
Alas, Object Pascal lacks a decent portable OS tasking interface.
With Delphi we successfully used Windows Messages for inter Thread
communication.
With FPC on Linux a friend of mine used System 5 Messages queues for the same
purpose.
Why don't you simply go ahead, implement something (cross-platform) and then
we can see how this can be integrated in FPC, if this integration is needed at all...
I did do first steps of this already some years ago. I hope I will be
able to start over in January.
-Michael
BTW.:
TPC comes with Free Vision.
The FPC IDE based on Free Vision seems to work fine.
The Free Vision Non-GUI seems to be event driven and thus needs to
implement a kind of event scheduler.
Maybe same might be worth looking at.
-Michael
___
Michael Schnell schrieb:
BTW.:
TPC comes with Free Vision.
The FPC IDE based on Free Vision seems to work fine.
The Free Vision Non-GUI seems to be event driven and thus needs to
implement a kind of event scheduler.
It's an event handling loop using queues for input events. Very primitive
Op Thu, 9 Nov 2006, schreef Florian Klaempfl:
Michael Schnell schrieb:
BTW.:
TPC comes with Free Vision.
The FPC IDE based on Free Vision seems to work fine.
The Free Vision Non-GUI seems to be event driven and thus needs to
implement a kind of event scheduler.
It's an
Daniël Mantione wrote:
Add to this the enable/disable system of commands. I.e. disable cmCut and all
menu
bars, status bars, buttons, context menu's and whatever thing
that can generate a cmCut turns grey.
In Delphi/VCL this is called a TAction, which can be assigned to
speedbutton,
On Thu, 9 Nov 2006, Daniël Mantione wrote:
Op Thu, 9 Nov 2006, schreef Florian Klaempfl:
Michael Schnell schrieb:
BTW.:
TPC comes with Free Vision.
The FPC IDE based on Free Vision seems to work fine.
The Free Vision Non-GUI seems to be event driven and thus
On Thu, 9 Nov 2006, Micha Nelissen wrote:
Daniël Mantione wrote:
Add to this the enable/disable system of commands. I.e. disable cmCut and
all menu
bars, status bars, buttons, context menu's and whatever thing
that can generate a cmCut turns grey.
In Delphi/VCL this is called a
As for general use, you can't do a Timer this way.
Right ! The beauty of TTimer (and GUI events as well) is that it does
not work in a thread. Otherwise it e.g. would not be possible to do GUI
stuff in a timer event, as VCL and LCL are not thread save (and probably
can't be made thread
On Wed, 8 Nov 2006, Michael Schnell wrote:
As for general use, you can't do a Timer this way.
Right ! The beauty of TTimer (and GUI events as well) is that it does not work
in a thread. Otherwise it e.g. would not be possible to do GUI stuff in a
timer event, as VCL and LCL are not
On st , 2006-11-08 at 07:35 +, Vinzent Hoefler wrote:
On Tuesday 07 November 2006 16:10, Ales Katona wrote:
As for general use, you can't do a Timer this way.
Believe me, I can. :)
You can't just put
a TTimer in which works in it's own thread and then calls some
callback in
Vinzent Hoefler wrote:
On Tuesday 07 November 2006 17:10, Michael Schnell wrote:
Of course, because the common concept of a timer is as asynchronous
as in "multi-threaded" or even "interrupt".
That is not true ! (See my other post.)
Well, a timer
There is TCustomApplication in fcl/inc/custapp. The Lazarus TApplication
descends
from it. All you need to do is create a descendent of TCustomApplication which
can implement all the messaging you wish for...
That sounds very good. :-) I'll take a look at this. (Supposedly in
January
On Wed, 8 Nov 2006, Vinzent Hoefler wrote:
On Wednesday 08 November 2006 09:16, Michael Van Canneyt wrote:
On Wed, 8 Nov 2006, Michael Schnell wrote:
As for general use, you can't do a Timer this way.
Right ! The beauty of TTimer (and GUI events as well) is that it
does not work
On Wednesday 08 November 2006 09:27, Ales Katona wrote:
On st , 2006-11-08 at 07:35 +, Vinzent Hoefler wrote:
On Tuesday 07 November 2006 16:10, Ales Katona wrote:
As for general use, you can't do a Timer this way.
Believe me, I can. :)
You can't just put
a TTimer in which
On Wednesday 08 November 2006 09:42, Michael Van Canneyt wrote:
On Wed, 8 Nov 2006, Vinzent Hoefler wrote:
On Wednesday 08 November 2006 09:16, Michael Van Canneyt wrote:
On Wed, 8 Nov 2006, Michael Schnell wrote:
As for general use, you can't do a Timer this way.
Right ! The
I even call the callback of another thread. :P
No you can't.
You still refuse to tell me why, so please stop telling me what I can't
do, especially when I *am* doing it.
Of course you can call any callback that exists in the application from
It all depends on what you're trying to accomplish. I still like to have
a asynchronous timer event model. It would still simplify some code.
You are right that this would be desirable.
Normal Delphi/Lazarus like TTimers are non-preemptive (you may call it
synchronous) for a good reason
On Wednesday 08 November 2006 10:01, Michael Schnell wrote:
But doing a function call (or hence using a callback) does not change
the thread context you are running in and thus you are still the same
thread. IOW: code lines are not _dedicated_ to a thread context.
Oh that, of course. Seems
It can't because X-Windows or MS-Windows are not thread-safe.
Yeah, right. And threading in DOS is not possible either, because DOS
is non-reentrant, is it?
You _can_ use threads in an X-Windows, MS-Windows or DOS environment,
you just can't do X-Windows, MS-Windows
You can call a callback in same thread, but since you can't ensure what
the callback does from your lib you can't make it threadsafe in any
way. Even if you put the callback itself into a criticalsection it
might eg: change some variable which was just in use by the main
thread, and once the
On Wednesday 08 November 2006 10:14, Michael Schnell wrote:
If you take a look the start of this thread, I mentioned that after
implementing Delphi/Lazarus like behavior for the main thread without
the need for a GUI, I'd like to enhance the concept by optionally
having an TApplication object
Well, I don't consider it beautiful, I consider it a hack. :)
It's beautiful, as the user does not need to care about mutually exclude
access of the objects that are used both in the main line code and the
timer callbacks. Most application programmers would not be able to
deal with this
Michael Van Canneyt wrote:
It can't because X-Windows or MS-Windows are not thread-safe.
FTR: AFAIK MS WinAPI is thread safe, just don't do stupid things
yourself of course (like passing buffers that are going to be messed
with by another thread and such).
Micha
If you take a look the start of this thread, I mentioned that after
implementing Delphi/Lazarus like behavior for the main thread without
the need for a GUI, I'd like to enhance the concept by optionally having
an TApplication object for any thread
Not every thread or program is event
On Wednesday 08 November 2006 10:26, Ales Katona wrote:
This is an old problem, and not fixable by wishing it. If you want a
good async. timer, sure make one, but don't expect it to work safely
by magic.
I'm sure I won't, I'm paranoid. :)
That's what I ment, it won't simply just work
Vinzent Hoefler wrote:
Maintaining
thread-safety ain't so complex once you start following some simple
rules.
Either you're underestimating thread-safety or you're a genius. Can you
document those simple rules on the wiki ?
Micha
___
fpc-devel
But now ... rereading the post, the original text was You can't just
put a TTimer in which works in it's own thread and then calls some
callback in it's own thread, and I still wonder why I shouldn't be
able to do that (well, if TTimer would actually do what its name
suggests and no-one else
Sorry, if it caused confusion, ...
No problem, taking more ideas as an input is always useful !
Thanks,
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Michael Schnell wrote:
the need for a GUI, I'd like to enhance the concept by optionally having
an TApplication object for any thread (e.g. TThread.Application) and
It shouldn't be named Application, because there is only one application
per process.
thus having an event scheduler for
Also I think a base thread should remain free from this. You can of course
create a descendant of tthread that is event driven (e.g. messagequeue, pump
and list of known events/methodvars in overriden tthread.execute)
Right. That is a decent way to do it optionally (as I of course would
do
Separate event scheduler and application.
Hint registered and saved in the to-do list :-)
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
This is not an async timer in the way Vincent meant it, assuming I
read his mails correctly. Also, pre-emptive multitasking is different
from the async timer as you're explaining here in exactly this detail.
An asynchronous timer needs to do a preemptive callback. Preemptive
execution needs
Michael Schnell wrote:
An asynchronous timer needs to do a preemptive callback.
No.
Preemptive
execution needs it's own thread.
No.
This is a way to provide the timer with
a thread.
Preemptive means same thread, as it 'preempts' it. That's what a (unix)
signal is. That's what
Michael Schnell wrote:
I don't see how async timers can be useful for software (maybe to
control hardware perhaps, but only the trivial kind as well, no complex
state allowed), as you cannot take any locks, and must be re-entrant.
No, not reentrant, unless you use the same event in the
Micha Nelissen wrote:
Michael Schnell wrote:
An asynchronous timer needs to do a preemptive callback.
No.
Ooops ? What is an asynchronous timer according to your definition ?
Preemptive execution needs it's own thread.
No.
Ooops ? What do you think is preemptive ? By definition
Micha Nelissen wrote:
Preemptive means same thread, as it 'preempts' it. That's what a (unix)
signal is. That's what Vincent meant (I think).
Sorry, Vinzent, it is.
Micha
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On Wednesday 08 November 2006 10:53, Micha Nelissen wrote:
Sorry for all the confusion, I'm trying to clarify what I actually mean
(or what I would *expect* from such a timer object):
I don't see how async timers can be useful for software (maybe to
control hardware perhaps, but only the
Vinzent Hoefler wrote:
So, the semantics would be about the same as in a signal (apart from the
softer timing), but you would have much less restrictions in the
handler's implementation compared to a real OS signal, which acts more
like an interrupt.
Impossible. You'll end with
On Wednesday 08 November 2006 12:44, Micha Nelissen wrote:
Vinzent Hoefler wrote:
So, the semantics would be about the same as in a signal (apart
from the softer timing), but you would have much less
restrictions in the handler's implementation compared to a real OS
signal, which acts
There is TCustomApplication in fcl/inc/custapp. The Lazarus TApplication
descends
from it. All you need to do is create a descendent of TCustomApplication which
can implement all the messaging you wish for...
I took a look at TCustomApplication. Same does not provide anything that
is
Vinzent Hoefler wrote:
repeat
SysUtils.Sleep (self.Interval);
self.Logger.Flush;
until self.Terminated;
is totally impossible to work? To implement something less crude you
It works, but it's not realtime by any definition.
Micha
On Wednesday 08 November 2006 13:21, Micha Nelissen wrote:
Vinzent Hoefler wrote:
repeat
SysUtils.Sleep (self.Interval);
self.Logger.Flush;
until self.Terminated;
is totally impossible to work? To implement something less crude
you
It works,
Oh wonder. A couple
On Wed, 8 Nov 2006, Michael Schnell wrote:
There is TCustomApplication in fcl/inc/custapp. The Lazarus TApplication
descends
from it. All you need to do is create a descendent of TCustomApplication
which
can implement all the messaging you wish for...
I took a look at
Michael Van Canneyt wrote:
TThread.Synchronize does not need to be changed. You can set a series
of callbacks (from classes unit) which you can then use to configure
the whole synchronize issue...
Sounds great !
Seems correct. And all this cross-platform, of course :-)
Of course !!!
On Wed, 8 Nov 2006, Michael Schnell wrote:
Michael Van Canneyt wrote:
TThread.Synchronize does not need to be changed. You can set a series
of callbacks (from classes unit) which you can then use to configure
the whole synchronize issue...
Sounds great !
Seems correct. And all
Vinzent Hoefler wrote:
but it's not realtime by any definition.
First, I never said real-time in that context and second: it sure can
I concluded that from your quote:
meta-quote
Timing events allow for a handler to be executed at a future point in
time in an efficient way, as it is a
On Wednesday 08 November 2006 14:43, Micha Nelissen wrote:
Vinzent Hoefler wrote:
but it's not realtime by any definition.
First, I never said real-time in that context and second: it sure
can
I concluded that from your quote:
meta-quote
Timing events allow for a handler to be
The answer to my I always thought a timer is more comparable to an
interrupt or signal than a polling loop. was That is a very common
misconception. which I still refuse as being a correct answer.
I misunderstood that you meant a Delphi TTimer. And I wanted to point
out that many Delphi
Vinzent Hoefler wrote:
The answer to my I always thought a timer is more comparable to an
interrupt or signal than a polling loop. was That is a very common
misconception. which I still refuse as being a correct answer.
The irony is of course that you clamp to your interrupt definition, but
Your code can perfectly be implemented as an add-on unit, which we can
distribute.
The first goal I see is that FPC comes with portable support for TTimer
and Delphi/Lazarus compatible thread support, that can be used in a
GUI-less Application - thus without Lazarus. If that's possible
On Wednesday 08 November 2006 16:08, Micha Nelissen wrote:
Vinzent Hoefler wrote:
The answer to my I always thought a timer is more comparable to an
interrupt or signal than a polling loop. was That is a very
common misconception. which I still refuse as being a correct
answer.
The
Hi FPC experts.
I read this thread in the list archive and as I'm very interested in
this topic (since years), I'm very happy do see this evolving and would
like to provide some comment (and maybe contribute some code once I'm up
to speed with FPC) and, of course, ask questions.
1) How is
On Tue, 7 Nov 2006, Michael Schnell wrote:
Hi FPC experts.
I read this thread in the list archive and as I'm very interested in this
topic (since years), I'm very happy do see this evolving and would like to
provide some comment (and maybe contribute some code once I'm up to speed with
On Tue, 7 Nov 2006, Micha Nelissen wrote:
Michael Van Canneyt wrote:
1) How is the state on this issue? Does the latest released version of the
FPC
RTL already provide a decent implementation of the threading primitives
known
from Delphi ? (e.g. TThread.Suspend,
It does.
Great !
None currently. Only 'Synchronize' is implemented.
Like with Delphi :-) :-( .
Feel free to implement this, but not as a language enhancement, a simple
unit should be enough.
..., at least for the beginning !
I'm sure I'll do this (supposedly in
Really ? Does TThread.Suspend work on linux ?
IMHO, the need for this function means your design is broken, but
maybe it's just me ...
As Delphi does provide TThread.Suspend, I suppose FPC should do so on
any platform (unless that is really impossible, which I don't think).
Of course you
On Tue, 7 Nov 2006, Michael Schnell wrote:
It does.
Great !
None currently. Only 'Synchronize' is implemented.
Like with Delphi :-) :-( .
Feel free to implement this, but not as a language enhancement, a simple
unit should be enough.
..., at least for the
..., at least for the beginning !
Why ? You don't need language enhancements for this IMHO. Scheduling and
messaging is OS territory, not programming language territory.
e.g. Ada provides multithreading means as language elements and AFAIK,
other languages also provide
On 07/11/06, Michael Schnell [EMAIL PROTECTED] wrote:
That's really bad ! IMHO it should be possible to use TTimer and TThread in
a simple non-GUI way. (I maybe will need to do an embedded project on an
ARM/Linux system that does not have X or any widget library.)
I would also love to see a
Graeme Geldenhuys wrote:
I would also love to see a TTimer in FPC rather than Lazarus. TTimer
without any GUI depenencies.
If the Eventer class in lNet can be moved into general FCL this would be
possible because I was planning to create a TLTimer, for use with lNet
eventer.
Micha
If the Eventer class in lNet can be moved into general FCL this would
be possible because I was planning to create a TLTimer, for use with
lNet eventer.
Could you elaborate on that (I don't know what lNet is at the moment).
But IMHO there should not be a separate TLTimer but the RTL (that
Michael Schnell wrote:
If the Eventer class in lNet can be moved into general FCL this would
be possible because I was planning to create a TLTimer, for use with
lNet eventer.
Could you elaborate on that (I don't know what lNet is at the moment).
lNet is a networking library, and has an
lNet is
a networking library, and has an internal event loop already
implemented, cross-platform.
Wouldn't it b e better to first implement an independent cross-platform
event loop ("Application!" thingy) in the RTL that can be used by
TTimer, TThread.Synchronize and lNet ?!?!?
If
On Tuesday 07 November 2006 12:42, Ales Katona wrote:
If you want a Timer a polling mechanism has to take place which
looks if something happened on some timer for example,
Is that so?
OnTimer is ready to be fired (you can't call callbacks in threads,
I can't call callbacks in threads?
Remember you need to call the HandleEvents as fast as possible to
stay effective (otherwise you lose precision)
I want to avoid this by any means !
That is why I want to have a message driven system (as described in the
other post):
TAppllication creates an event from a message
I can't call callbacks in threads? Why's that? Or am I understanding
something wrong?
Of course you can use "events" (aka class properties that are
functions) in threads. That is just the Object Pascal syntax. But in
the main thread in Delphi or Lazarus events of GUI objects (e.g.
On Tuesday 07 November 2006 14:47, Michael Schnell wrote:
Well, for me it would have saved me some time which I wasted in
creating threads that implement timing events by simply sleeping
for a particular time.
IMHO this should be done following the Delphi paradigms to be nice to
Delphi
This is how lNet already works, no ? Where's the difference ?
Indeed but it's only there because there's no other way, if I could just
make it magicly work without CallAction I'd love to.
You can't call callbacks in threads (you can but only in one thread, not
between threads), and you can't
On Tuesday 07 November 2006 15:17, Ales Katona wrote:
So eg: if you want to do something every 1000ms, you could put a
TThread based timer in, and make it Sleep(1000) and then call the
code, but you must be sure that your main thread cannot have
conflicts if this code is called at any time
On Tuesday 07 November 2006 15.14, Michael Schnell wrote:
Remember you need to call the HandleEvents as fast as possible to
stay effective (otherwise you lose precision)
I want to avoid this by any means !
That is why I want to have a message driven system (as described in the
other
Of course, because the common concept of a timer is as asynchronous as
in multi-threaded or even interrupt.
You're not seriously trying to work around that simple fact, do you?
Actualy I am, because lNet is single-threaded non-blocking.
As for general use, you can't do a Timer this
I don't
even care, because I simply don't understand what time as in timer
has to do with graphics as in graphical. For me that's two
completely different subjects unless we're talking about animations
where those two subjects meet.
Viewing from top you are right, and I do need a platform
The big advantage is that you do not need to protect any resources
from multi-threaded access if you do not explicitly create a thread
by means of TThread.
And the big disadvantage seems to be a overly complicated programming
model. Guess, what I'd prefer.
As said, we
MSEgui has teventthread (lib/common/kernel/msethread.pas), there is also a
timer implementation (lib/common/kernel/msetimer.pas).
http://mypage.bluewin.ch/msegui/
Thanks for the pointer. I'll take a look at this tomorrow.
What is the purpose of msetimer ?
Do you think this can show a
On Tue, 7 Nov 2006, Michael Schnell wrote:
I don't even care, because I simply don't understand what time as in
timer has to do with graphics as in graphical. For me that's two
completely different subjects unless we're talking about animations where
those two subjects meet.
Viewing
On Tuesday 07 November 2006 18.34, Michael Schnell wrote:
MSEgui has teventthread (lib/common/kernel/msethread.pas), there is also
a timer implementation (lib/common/kernel/msetimer.pas).
http://mypage.bluewin.ch/msegui/
Thanks for the pointer. I'll take a look at this tomorrow.
What
On Tuesday 07 November 2006 16:10, Ales Katona wrote:
As for general use, you can't do a Timer this way.
Believe me, I can. :)
You can't just put
a TTimer in which works in it's own thread and then calls some
callback in it's own thread,
I even call the callback of another thread. :P
On Tuesday 07 November 2006 17:10, Michael Schnell wrote:
Of course, because the common concept of a timer is as asynchronous
as in multi-threaded or even interrupt.
That is not true ! (See my other post.)
Well, a timer is, even though the Delphi implementation of a so-called
TTimer object
Op Tue, 17 Oct 2006, schreef Jonas Maebe:
On 16 okt 2006, at 22:49, Daniël Mantione wrote:
In other works, pthreads results
in subpar performance,
Is the overhead of a few user level routines really that big? Once the threads
are setup, they automatically become kernel threads
On 17 okt 2006, at 09:25, Daniël Mantione wrote:
If I compare my implementation of the Chameneos benchmark with the one
from Marc (which uses Pthreads directly), mine is about two times
slower.
This is propably caused that our thread functions often require
multiple
Pthread calls,
Op Tue, 17 Oct 2006, schreef Jonas Maebe:
On 17 okt 2006, at 09:25, Daniël Mantione wrote:
If I compare my implementation of the Chameneos benchmark with the one
from Marc (which uses Pthreads directly), mine is about two times slower.
This is propably caused that our thread
Daniël Mantione wrote:
Op Tue, 17 Oct 2006, schreef Jonas Maebe:
On 17 okt 2006, at 09:25, Daniël Mantione wrote:
If I compare my implementation of the Chameneos benchmark with the one
from Marc (which uses Pthreads directly), mine is about two times slower.
This is propably caused that our
Marc Weustink wrote:
This was exactly the reason why I choose to use pthreads directly. For
the given situation one single semaphore call could replace this.
Well, events semaphores :-). We need semaphore abstraction as well
for proper RTL, besides events.
Micha
Op Tue, 17 Oct 2006, schreef Micha Nelissen:
Marc Weustink wrote:
This was exactly the reason why I choose to use pthreads directly. For
the given situation one single semaphore call could replace this.
Well, events semaphores :-). We need semaphore abstraction as well for
proper RTL,
Daniël Mantione wrote:
no kernel call is necessary. If the lock starts spinning, on uniprocessor
it won't be released until the kernel schedules the other thread. This
exactly the idea behind kernel futexes, if the lock is not held, no kernel
Aren't futexes 2.6+ only ?
Micha
On 17 okt 2006, at 10:44, Daniël Mantione wrote:
procedure intRTLEventSetEvent(AEvent: PRTLEvent);
var p:pintrtlevent;
begin
p:=pintrtlevent(aevent);
pthread_mutex_lock(@p^.mutex);
pthread_cond_signal(@p^.condvar);
pthread_mutex_unlock(@p^.mutex);
end;
procedure
On Tuesday 17 October 2006 09:03, Jonas Maebe wrote:
On 17 okt 2006, at 10:44, Daniël Mantione wrote:
procedure intRTLEventSetEvent(AEvent: PRTLEvent);
var p:pintrtlevent;
begin
p:=pintrtlevent(aevent);
pthread_mutex_lock(@p^.mutex);
pthread_cond_signal(@p^.condvar);
[ Charset ISO-8859-1 unsupported, converting... ]
Jonas Maebe wrote:
Not sure if this means it's not necessary in the Mac OS X (and possibly
FreeBSD) versions, or that the Mac OS X man pages are incomplete.
It does say: The pthread_cond_signal() function unblocks one thread
waiting for
On 17 okt 2006, at 11:50, Micha Nelissen wrote:
Jonas Maebe wrote:
Not sure if this means it's not necessary in the Mac OS X (and
possibly FreeBSD) versions, or that the Mac OS X man pages are
incomplete.
It does say: The pthread_cond_signal() function unblocks one thread
waiting for
On 17 okt 2006, at 11:58, Jonas Maebe wrote:
Not necessarily, it is at least possible to implement an atomic
linked list without requiring a mutex-style lock.
... using the atomic primitives of the PPC processor. Maybe it's not
possible in general...
Jonas
On Tuesday 17 October 2006 09:46, Jonas Maebe wrote:
On 17 okt 2006, at 11:22, Vinzent Hoefler wrote:
The pthread_cond_wait() function atomically unlocks the
mutex argument
and waits on the cond argument.
So the mutex should already be unlocked afterwards.
If you would
Jonas Maebe wrote:
By implication this means you need a mutex to protect against race
conditions.
Not necessarily, it is at least possible to implement an atomic linked
list without requiring a mutex-style lock.
That's irrelevant. If thread 1 lets thread 2 do something, and thread 2
would
On Tuesday 17 October 2006 10:03, Micha Nelissen wrote:
Windows events do not have this problem since they are stateful.
To be more precise: Windows signals are persistent, not transient like
Unix signals are.
Vinzent.
___
fpc-devel maillist -
Op Tue, 17 Oct 2006, schreef Micha Nelissen:
Daniël Mantione wrote:
no kernel call is necessary. If the lock starts spinning, on uniprocessor
it won't be released until the kernel schedules the other thread. This
exactly the idea behind kernel futexes, if the lock is not held, no
I've implemented the semaphores stuff (with a big bad bug, btw thanks
Jonas for fixing).
Right now I'm thinking about how to go next.
The choices I see right now are:
1. Basicly just clean the current pthreads implementation, make sure
types are not redefined in baseunix/unixtypes and pthreads
Op Mon, 16 Oct 2006, schreef Ales Katona:
Write your ideas on the subject please.
Short answer: Kick pthreads and use kernel threads.
Daniël___
fpc-devel maillist - fpc-devel@lists.freepascal.org
1 - 100 of 107 matches
Mail list logo
