On Wed, 8 Nov 2006, Michael Schnell wrote:
Jonas Maebe wrote:
Does anyone see a problem with the following CSuspendThread/CResumeThread
implementations?
1) This of course is the Linux version. Are the other implementation already
in place so that the result is platform independent
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
On 8 nov 2006, at 10:05, Michael Schnell wrote:
Does anyone see a problem with the following CSuspendThread/
CResumeThread implementations?
1) This of course is the Linux version.
No, it's the generic *nix version (i.e., also used for Free/Net/
OpenBSD, Darwin and Solaris).
Are the
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
Jonas currently fpc2.1.1 doesn't compile on 2.1.1 with:
rtl/units/i386-freebsd -di386 -dRELEASE ../unix/cthreads.pp
cthreads.pp(252,42) Error: Incompatible type for arg no. 1: Got
LongInt, expected Pointer
Note:
unixtypes thread_t = pointer
pthreads.inc thread_t (BSD and linux) = cInt {linux is
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 Wed, 8 Nov 2006, Ales Katona wrote:
Jonas currently fpc2.1.1 doesn't compile on 2.1.1 with:
rtl/units/i386-freebsd -di386 -dRELEASE ../unix/cthreads.pp
cthreads.pp(252,42) Error: Incompatible type for arg no. 1: Got
LongInt, expected Pointer
Note:
unixtypes thread_t = pointer
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
Note:
unixtypes thread_t = pointer
Wrong, same as in ptypes.inc
pthreads.inc thread_t (BSD and linux) = cInt {linux is Longint but
that's just bug)
freebsd/pthreads.inc doesn't define thread_t, neither does the linux
version?
There is a small issue with tthreadid which is already used to
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
On 8 nov 2006, at 10:42, Ales Katona wrote:
Jonas currently fpc2.1.1 doesn't compile on 2.1.1 with:
rtl/units/i386-freebsd -di386 -dRELEASE ../unix/cthreads.pp
cthreads.pp(252,42) Error: Incompatible type for arg no. 1: Got
LongInt, expected Pointer
So either TThreadID or pthread_t is
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
A cleaner naming of problematic parts:
1. TThreadID is defined stand-alone not as a pthread_t, should be fixed.
2. TThreadHandler (the callback for resume, suspend) has result as DWord
while posix stuff (pthread_kill etc.) usualy return cInt
3. in linux I saw pthreads functions return longint, I
On 8 nov 2006, at 11:16, Ales Katona wrote:
A cleaner naming of problematic parts:
1. TThreadID is defined stand-alone not as a pthread_t, should be
fixed.
2. TThreadHandler (the callback for resume, suspend) has result as
DWord
while posix stuff (pthread_kill etc.) usualy return cInt
3.
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
On Wed, 8 Nov 2006, Ales Katona wrote:
A cleaner naming of problematic parts:
1. TThreadID is defined stand-alone not as a pthread_t, should be fixed.
2. TThreadHandler (the callback for resume, suspend) has result as DWord
while posix stuff (pthread_kill etc.) usualy return cInt
Just
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
On Wednesday 08 November 2006 10.25, Jonas Maebe wrote:
On 8 nov 2006, at 06:52, Martin Schreiber wrote:
But what should we do if we can't use trunk because it is not
stable and we
can't use 2.0.4 because it is buggy?
There will *always* be bugs in the latest release which cause it not
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
On 8 nov 2006, at 11:47, Martin Schreiber wrote:
There will *always* be bugs in the latest release which cause it not
to work for some people. If we'd release a 2.0.6, that situation
would not change and some of those people would also think that their
bug is so important it requires a new
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
On 8 nov 2006, at 11:21, Jonas Maebe wrote:
Question about #2. Well.. this is a tough nut? I suspect it's
because of
various threading backends, but we need to handle those -1
properly if
nothing else but this implies going over by all used pthread
functions
and seeing all possible
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
Can someone give me a reference to static single use (for example scientific
paper).
I know SSA and SSI (I = information).
Thanks
--Bart.
_
Een eigen webpagina voor foto's en weblog in 2 tellen!
http://spaces.live.com
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 8 nov 2006, at 17:11, Bart van den Broek wrote:
Can someone give me a reference to static single use (for example
scientific paper).
I know SSA and SSI (I = information).
http://www.google.com/search?q=static+single+use
First hit (the Google summary even contains all necessary
Jonas Maebe wrote:
On 8 nov 2006, at 17:11, Bart van den Broek wrote:
Can someone give me a reference to static single use (for example
scientific paper).
I know SSA and SSI (I = information).
http://www.google.com/search?q=static+single+use
Is SSU easier to implement than SSA ? Aren't
All links you gave me lead to SSA, I have gathered quite some documents on
the subject.
I found one reference in an SSI document to SSU and it was discredited as
incomplete (no algorithms) and vague.
I thought you found some info i didnt see yet.
So i guess you are using SSA?
--Bart.
On 8 nov 2006, at 17:46, Micha Nelissen wrote:
Jonas Maebe wrote:
On 8 nov 2006, at 17:11, Bart van den Broek wrote:
Can someone give me a reference to static single use (for example
scientific paper).
I know SSA and SSI (I = information).
http://www.google.com/search?q=static+single+use
On 8 nov 2006, at 17:58, Bart van den Broek wrote:
All links you gave me lead to SSA,
No. The first google hit is a wikipedia article about SSA, but
contains a subsection about SSU.
I have gathered quite some documents on the subject.
I found one reference in an SSI document to SSU and
No. The first google hit is a wikipedia article about SSA, but
contains a subsection about SSU.
Ah found it (but no articles/reports that compares it with SSA).
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Jonas Maebe schreef:
On 8 nov 2006, at 17:46, Micha Nelissen wrote:
Is SSU easier to implement than SSA ?
No, it's a bit more work.
Aren't variables often more used than assigned (so more generated
variables by SSU) ?
Yes.
How do the achieved optimizations compare ?
SSU gives
On 08 Nov 2006, at 20:13, Vincent Snijders wrote:
Will you be working on SSA and/or SSU with control blocks (e.g.
using SSA in procedures where a for loop is used) before 2.2? Or
will that be released only in a later version.
Later. But maybe Florian will work on it earlier.
Jonas
Jonas Maebe schrieb:
On 08 Nov 2006, at 20:13, Vincent Snijders wrote:
Will you be working on SSA and/or SSU with control blocks (e.g. using
SSA in procedures where a for loop is used) before 2.2? Or will that
be released only in a later version.
Later. But maybe Florian will work on it
(However, to view some articles you must have subscription.)
Which is also my problem
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Just define an opaque type TThreadResult:
TThreadResult = DWord // Windows
TThreadResult = cInt // Unices
I don't like this solution for several reasons:
1. What if one OS has more backends for threading available, which
differ in this?
2. How are we going to handle error states on
On Wed, 8 Nov 2006, Ales Katona wrote:
Just define an opaque type TThreadResult:
TThreadResult = DWord // Windows
TThreadResult = cInt // Unices
I don't like this solution for several reasons:
1. What if one OS has more backends for threading available, which
differ in this?
Whoever first told me about bad input from lNet telnet example, could
you please try again to see if it still persists?
I did some fixes related to input and certain telnet commands recently
which might fix it.
Thanks (sorry I forgot who it was and deleted the mail since then)
Ales
I just read your posting on Delphi's DivMod. It doesn't work very well, not on
LongInt (Integer) values and negatives, not on Delphi 6, that I'm using, anyway.
I wrote an alternative that handles LongInt and negatives. It takes only
Integer parameters. It's a function, rather than a
function DivWithRemainder(Value, Divisor: Integer; var Remainder: Integer):
Integer;
{
In:
EAX = Value
ECX = @Remainder
EDX = Divisor
Out:
EAX = Result
ECX = @Remainder
}
asm
PUSH EBX { Save EBX - this register is not free to use }
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
Op Thu, 9 Nov 2006, schreef Florian Klaempfl:
Is this really faster than using CDQ?
At least on RISC86 CPU's, CDQ is a fast directpath instruction.
Daniël___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Daniël Mantione schrieb:
Op Thu, 9 Nov 2006, schreef Florian Klaempfl:
Is this really faster than using CDQ?
At least on RISC86 CPU's, CDQ is a fast directpath instruction.
That's why I'am asking :)
___
fpc-devel maillist -
74 matches
Mail list logo
