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 ?
2) In Linux we have the old ("Linux thread" ->
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 i
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 save).
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 Wednesday 08 November 2006 09:15, Michael Schnell wrote:
> Right ! The beauty of TTimer (and GUI events as well) is that it does
> not work in a thread.
Well, I don't consider it beautiful, I consider it a hack. :)
Vinzent.
___
fpc-devel maillist
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
to work for some people. If we'd release a 2.0.6, that sit
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
> > cal
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 in a thread. Otherwise it e.g. would not b
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 i
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 other
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
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
> >
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 = po
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 T
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.
> > > >
> >
> 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 t
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
anywher
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 de
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 t
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. Seem
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 or
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 obj
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
Jus
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 wi
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 mai
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 els
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 i
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 rele
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 same.
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
No, the timer will still be synchronous, only to the current thread's
event handler, not to the main (GUI) one.
These timers are assigned to a thread.
They are synchronous (non-preemptive) regarding their own thread and
asynchronous (preemptive) regarding all other threads. So, by accessing
FPC does not decide anything. The pthread library decides this.
AFAIK this means that with Kernel 2.4 this will be a Linux process for
each thread and with Kernel 2.6 this will be NPTL and thus only one
process. So both ways need to be verified to work with the implementations.
-Michael
Michael Schnell wrote:
I don't see how async timers can be useful for software
It decreases the latency. This is always the reason to do _preemptive_
multitasking.
This is not an async timer in the way Vincent meant it, assuming I read
his mails correctly. Also, pre-emptive multitasking is di
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 it
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 Vincent
> 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 t
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 values
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 preempti
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
http://lists.freepa
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 tri
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 TThread.Sync
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, whic
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 relate
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 w
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 loo
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 corr
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:
Timing events allow for a handler to be executed at a future point in
time in an efficient way, as it is a standalone ti
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:
>
>
> 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, bu
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
_
Op Wed, 8 Nov 2006, schreef Bart van den Broek:
> Can someone give me a reference to static single use (for example scientific
> paper).
> I know SSA and SSI (I = information).
http://www.freepascal.org/wiki/index.php/Single_assignment
Daniël___
fpc-
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 wit
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 informati
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 va
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.
Ori
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 i
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
http://lists.freepascal.org/mai
> Ah found it (but no articles/reports that compares it with SSA).
There are some bibliographies: http://www.cs.man.ac.uk/~irogers/SSA.xhtml and
http://www.cs.man.ac.uk/~jsinger/ssa.html (with comments). (However, to view
some articles you must have subscription.)
___
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 somewh
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 ear
(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 state
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
>
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 procedure
> 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 f
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
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
http://lists.freepascal.org/mailman/
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 - fpc-devel@li
83 matches
Mail list logo