Board index » kylix » Re: Kylix now officially alive?

Re: Kylix now officially alive?


2004-12-30 02:22:22 AM
kylix1
Is the OP wanting all the signalling to happen within a single process? I
thought s/he was looking for IPC.
Rob
"Michael Schnell" < XXXX@XXXXX.COM >wrote in message
Quote
>>Additionnaly fireing an event in a TThread when a message arrives would
>>be great, but I suppose a TThread "event scheduler" would need to be
>>designend for this.
>
>
>That's implicit in Windows, isn't it? Or I'm missing what you mean.
What
>about the windows message queue?
>


Hmm, in Delphi/Windows/VCL you hook a message with

type
TForm1234 = class(TForm)
procedure Message1234(var Message: TWMChar); message 1234;

in a TForm type declaration.


So a message sent to the Window that is created by a (the only) instance
of TForm1234 arrives, fires the Message1234 event.

In a TThread you are not allowed to use any VCL functions that do any
Window handling and thus, AFAIK, you can't create a Window in a thread.
That means that you can't attach an event to a message in the Delphi/VCL
way.

-Michael
 
 

Re:Re: Kylix now officially alive?

Quote
IPC, since the classic unix server model forks a new process, doesn't create
threads. (windows: relative cheap threads, expensive processes,
Of course correct.
Quote
unix other way around)
IMHO not true (any more). In Linux you always could create processes
with shared memory (and file handles). I don't think that is more
expensive than completely separate processes. With Kernel 2.6 you have
the new thread model that is used via the Posix Thread library. These
threads are created and scheduled extremely fast, even faster than
separate Linux processes and Windows threads. Moreover you have user
land semaphores to do extremely fast inter thread synchronizing.
Quote
>This leaves a single event that is to be fired on behalf of a semaphore
>(TEvent) freed by a thread, i.e. by adding an "OnFired" event property
>to TEvent.


The problem is how you send something to a thread without polling.

The way it is done in Delphi only works for the main thread since that one
is event driven in principle (and latency is avoided via
application.processmessages), and, less important, has got a message window

That's the {*word*193} old Windows only method :(
Quote
Threads don't (maybe they have something to send msgs too, but that's why
that one is less important). So what will maintain and poll that event queue
in a tthread?

Do you envision a special event driven thread type that contains this
system, analogue to the application object for the main thread?

I suppose, if you build an appropriate RTL you can do this in the same
way for the main thread and the TThreads, without using asymmetric OS
inherited stuff. E.g.:
- a thread-semaphore per thread (that primitive is available in any
OS) could be the basis to which all events return (in main thread and in
TThreads)
- a "message queue" in the RTL (a TThreadList or something more
dedicated) is used as a FiFo fro incoming messages.
- a return from an Event handler in user code branches to a scheduler
that tests if a message is available, if yes it handles same by a user
or RTL/VCL/CLX/LCL event and waits for the semaphore if no.
- a message is sent to the main thread or the thread by writing it
into the FiFo and releasing the semaphore (if taken).
- a GUI event message is converted to a message to the main thread by
the RTL/VCL/CLX/LCL. (The RTL/VCL/CLX/LCL has a mechanism <like Delphi,
Kylix, FP and Lazarus have>that fires different events depending on the
message value, while a TThread supposedly only has a single event in
RTL, having the user do all the message value handling.)
- TThread gets a "WaitMessage" function that jumps to the RTL
scheduler function and has the thread wait for the threads message
semaphore and never returns, but calls the "OnMessage" handler when a
message arrives.
- TThread (or TEvent) is equipped with an "OnMessage" (or "OnFired")
event that gets called when a message arrives.
So you can do event driven (object-) programming in a TThread like you
do it in the main thread.
Quote

As said, main is special in other ways. However that could be dealt with
in a tthread derivative.
I _hope_ that can be handled by another abstraction layer (see above).
The RTL (and language) creates a symmetric event handling system for
main and other threads, only the GUI sends it's messages exclusively to
the main thread (and ignores the other threads), by a layer that
converts GUI messages to RTL/language messages.
-Michael
 

Re:Re: Kylix now officially alive?

Quote
Is the OP wanting all the signalling to happen within a single process? I
thought s/he was looking for IPC.

The VCL is to be blamed here.
I don't know how it's done in Kylix/Linux, but in Windows you send a
message to a Window (that can be hidden, if you don't want it to show up
ion the GUI). The Delphi VCL is not thread save and so you are not
allowed to call VCL functions that are related to windows in a TThread.
So we have different incompatible sets of inter thread communication means:
- messages that fire main thread events in Delphi/VCL/Windows,
- messages that fire main thread events in CLX using different code,
- direct calls to OS functions to send messages to and wait for
messages in TThreads, of course different code in Windows and in Linux.
IMHO not a perfect situation at all.
-Michael
 

{smallsort}

Re:Re: Kylix now officially alive?

Marco van de Voort wrote:
Quote
Threads don't (maybe they have something to send msgs too, but that's why
that one is less important). So what will maintain and poll that event
queue in a tthread?
What about signals? I have a unit that executes a function/method in
another thread's context. So you could "inject" the function into a
thread's context, interrupting this thread. No polling is necessary.
function TMyClass.MyThreadEventHandler(Handle: TThreadCallHandle; Params:
array of Integer): Integer;
begin
case Params[0] of
MyEvent:
DoSomething;
end;
Result := 0;
end;
var
tch: TThreadCallHandle;
begin
tch := CreateThreadCall(MyThreadId, MyObject.MyThreadEventHandler);
try
ThreadCallNoWait(tch, [MyEvent]);
DoSomethingThatTakesALotOfTime;
finally
DestroyThreadCall(tch);
end;
end;
With some changes this code could just look like this:
ThreadCallNoWait(MyThreadId, MyThreadEventHandler, [MyEvent]);
--
Regards,
Andreas Hausladen
 

Re:Re: Kylix now officially alive?

On 2004-12-29, Michael Schnell < XXXX@XXXXX.COM >wrote:
Quote
>IPC, since the classic unix server model forks a new process, doesn't create
>threads. (windows: relative cheap threads, expensive processes,

Of course correct.
A.S. 1 Did I mention I'm a FreeBSD user? Solutions must work on any Linux
(not just x86),win32, *BSD and Darwin)
A.S. 2 I'm not a threading or Unix IPC god, I only just started, but are
learning fast now. My first interests is getting Indy
ported to fpc, since I urgently (as in preferably before summer)
need Indy on 64-bit Linux.[A
A.S. 3 As of yesterday, FPC/Lazarus have working .synchronize on at least
linux (based on pthread_cond_* calls)
Quote
>unix other way around)

IMHO not true (any more). In Linux you always could create processes
with shared memory (and file handles).
Anyway, yes this is true, using clone (on SysV) or rfork (on BSD). However
the cost of spawning then increases again.
Quote
I don't think that is more expensive than completely separate processes.
Afaik it is more expensive still.
Quote
With Kernel 2.6 you have the new thread model that is used via the Posix
Thread library. These threads are created and scheduled extremely fast,
even faster than separate Linux processes and Windows threads. Moreover
you have user land semaphores to do extremely fast inter thread
synchronizing.
Yeah, m:n scheduling. FreeBSD has KSE which is similar. However I don't know
if it extends to all IPC elements. However everything got a thorough speedup
and debugging.
Quote
>>This leaves a single event that is to be fired on behalf of a semaphore
>>(TEvent) freed by a thread, i.e. by adding an "OnFired" event property
>>to TEvent.
>
>
>The problem is how you send something to a thread without polling.
>
>The way it is done in Delphi only works for the main thread since that one
>is event driven in principle (and latency is avoided via
>application.processmessages), and, less important, has got a message window

That's the {*word*193} old Windows only method :(
Based on Windows msgs: yes. The principle of main GUI thread being
eventdriven: no.
The event driven solution is quick and elegant. Kernel calls always
slow down.
Quote
>Threads don't (maybe they have something to send msgs too, but that's why
>that one is less important). So what will maintain and poll that event queue
>in a tthread?
>
>Do you envision a special event driven thread type that contains this
>system, analogue to the application object for the main thread?

I suppose, if you build an appropriate RTL you can do this in the same
way for the main thread and the TThreads, without using asymmetric OS
inherited stuff. E.g.:
- a thread-semaphore per thread (that primitive is available in any
OS) could be the basis to which all events return (in main thread and in
TThreads)
(..)
- a message is sent to the main thread or the thread by writing it
into the FiFo and releasing the semaphore (if taken).
Yes, that is roughly what I had in mind too, and what is what I meant by
event driven threads, Since this model is more or less event driven already,
(the sleep in the semaphore takes the place of the block on a getevent call
in windows). For the rest, effectively the queue just changes from kernel to
userspace.
However I still see a possible problem. Afaik basic semaphores don't carry
data like windows messages? Or is the practical pthreads definition other
than the theoretical sempahore?
Quote
- a GUI event message is converted to a message to the main thread by
the RTL/VCL/CLX/LCL. (The RTL/VCL/CLX/LCL has a mechanism <like Delphi,
Kylix, FP and Lazarus have>that fires different events depending on the
message value, while a TThread supposedly only has a single event in
RTL, having the user do all the message value handling.)
This goes beyond having a user messages system, so now you want a full
thread safe GUI system?
Aren't you scared
1) that all the locking and OS IPC overhead will systematically slow down
everything and give the GUI
2) the complexity increase will make it hard to stabilise/debug the RTL
(see Indy and its never ending series of bugs)
What do you see as the major benefits of your that? IOW, what do you see
as typical use for such an event driven thread system?
Quote
- TThread (or TEvent) is equipped with an "OnMessage" (or "OnFired")
event that gets called when a message arrives.

So you can do event driven (object-) programming in a TThread like you
do it in the main thread.
Me too, but I don't need that for GUI. I was thinking more about a tthread
descendant with this eventdriven mechanism for user specific purposes,
without system integration.
Quote
>As said, main is special in other ways. However that could be dealt with
>in a tthread derivative.

I _hope_ that can be handled by another abstraction layer (see above).
The RTL (and language) creates a symmetric event handling system for
main and other threads, only the GUI sends it's messages exclusively to
the main thread (and ignores the other threads), by a layer that
converts GUI messages to RTL/language messages.
I don't think you want GUI message flow with its multitude and magnitude
of events over this.
I already more or less do such a thing now in my Delphi app btw, win32 only
The main thread gets all events;
- socket ones from threads
- events from code watching the filesystems
- custom GUI events from the UI. (so no 1:1 windows msg: event equivalence)
however the actions of statemachine mostly don't require sending messages
back to the threads now. The main thread can handle them.
 

Re:Re: Kylix now officially alive?

On 2004-12-29, Andreas Hausladen < XXXX@XXXXX.COM >wrote:
Quote
Marco van de Voort wrote:

>Threads don't (maybe they have something to send msgs too, but that's why
>that one is less important). So what will maintain and poll that event
>queue in a tthread?

What about signals? I have a unit that executes a function/method in
another thread's context. So you could "inject" the function into a
thread's context, interrupting this thread. No polling is necessary.
Slow I think. But how can one do something useful with it then? Since the
event would typically put data in fields of the thread, and you can't
protect that with a simple criticalsection, since if the thread doesn't run,
and deadlock would occur
I found the unit here:
www.web-one.org/new-4921122-4890.html
Do you have an example, preferably one that e.g. does some producer-consumer
with it? I'll then save it to my todo list, and see if I can get it to run
on FreeBSD.
 

Re:Re: Kylix now officially alive?

Marco van de Voort wrote:
Quote
Slow I think. But how can one do something useful with it then?
I don't know. I had written the unit only because I was interested in how
it would work.
Quote
I found the unit here:
www.web-one.org/new-4921122-4890.html
That is an old one with a major issue that can cause execution in the
wrong thread because the pipe is linear but the scheduler isn't.
Quote
Do you have an example, preferably one that e.g. does some
producer-consumer with it? I'll then save it to my todo list, and see if
I can get it to run on FreeBSD.
I'm looking on my Linux partition for it. ( I hope I have not deleted it
since the last distribution upgrade ).
--
Regards,
Andreas Hausladen
(www.kylix-patch.de.vu - unofficial Kylix 3 patches)
(andy.jgknet.de/blog)
 

Re:Re: Kylix now officially alive?

Quote

A.S. 1 Did I mention I'm a FreeBSD user? Solutions must work on any Linux
(not just x86),win32, *BSD and Darwin)
I suppose the Posix Thread library is available on any decent *nix
Quote
A.S. 2 I'm not a threading or Unix IPC god, I only just started, but are
learning fast now. My first interests is getting Indy
ported to fpc, since I urgently (as in preferably before summer)
need Indy on 64-bit Linux.[A
Sounds like a very interesting and useful task !
Quote
A.S. 3 As of yesterday, FPC/Lazarus have working .synchronize on at least
linux (based on pthread_cond_* calls)


Great ! This at least helps with porting simple multi threaded Delphi
projects.
-Michael
 

Re:Re: Kylix now officially alive?

Marco van de Voort wrote:
Here the code that I had used for testing (and the newer unit version
without pipes)
andy.jgknet.de/oss/Delphi/ThreadCallSys.zip
--
Regards,
Andreas Hausladen
(www.kylix-patch.de.vu - unofficial Kylix 3 patches)
(andy.jgknet.de/blog)
 

Re:Re: Kylix now officially alive?

Quote
Yes, that is roughly what I had in mind too, and what is what I meant by
event driven threads, Since this model is more or less event driven already,
(the sleep in the semaphore takes the place of the block on a getevent call
in windows). For the rest, effectively the queue just changes from kernel to
userspace.
That might speed things up. The semaphores can be partly in user pace
too, either by coding it in the RTL (calling a system semaphore only if
there is no waiting message (being aware of multithreadding /
multiprocessing issues and thus using a bus blocking bit test and set
instruction) ) or by using the new Linux user space semaphore.
Quote

However I still see a possible problem. Afaik basic semaphores don't carry
data like windows messages?
Of course not. That is why I suggest a user space message FiHo per
thread. We need a semaphore per thread. Maybe we need to be aware that
Windows semaphores are binary, Linux System V semaphores are counting. I
don't know much about the new user space semaphores and if there is
another kind of semaphores in the PThread Library.
Quote
Or is the practical pthreads definition other
than the theoretical sempahore?

There are different implementations but I think we need a simple binary
behavior and that should be doable with all of them.
Quote

>- a GUI event message is converted to a message to the main thread by
>the RTL/VCL/CLX/LCL. (The RTL/VCL/CLX/LCL has a mechanism <like Delphi,
>Kylix, FP and Lazarus have>that fires different events depending on the
>message value, while a TThread supposedly only has a single event in
>RTL, having the user do all the message value handling.)


This goes beyond having a user messages system, so now you want a full
thread safe GUI system?

No. Like in Delphi only the main thread is allowed to do Gui handling. I
just suggest the additional layer that allows for the same low level
message handling for all threads to simplify the RTL.
Quote
Aren't you scared

1) that all the locking and OS IPC overhead will systematically slow down
everything and give the GUI
In Delphi, a GUI event that calls a Delphi event gets in the system
message queue and the system seems to directly call the VCL event that
is attached when creating the VCL object instance. Now we would need to
have the system call a single central event and dispatch the event
"manually" in the RTL. Of course this will impose some overhead to the
GUI events. I can't estimate if that will result in a noticibly slow down.
Quote
2) the complexity increase will make it hard to stabilise/debug the RTL
(see Indy and its never ending series of bugs)

No idea.
Quote
What do you see as the major benefits of your that? IOW, what do you see
as typical use for such an event driven thread system?


In the moment in Delphi you need to think linear (similar to procedural)
when creating a thread and event driven (similar to object thinking) in
the main thread. That's acceptable for small thread code but can get
quite confusing with big ones.
BTW.: the suggestion of doing the main thread message queue the way
described is just to simplify the RTL. The same result for the user can
be achieved by doing different message queue implementations for the
main thread (that provides GUI handling) and the TThreads. Doing so
there would be no performance panelty for the GUI. But the RTL code
would need more "ifs" to take care of the different OSes.
Quote
>- TThread (or TEvent) is equipped with an "OnMessage" (or "OnFired")
>event that gets called when a message arrives.
>
>So you can do event driven (object-) programming in a TThread like you
>do it in the main thread.


Me too, but I don't need that for GUI. I was thinking more about a tthread
descendant with this eventdriven mechanism for user specific purposes,
without system integration.

Right. That would mean different message code for main and TThread. I
don't object to that at all.
Quote

I already more or less do such a thing now in my Delphi app btw, win32 only
The main thread gets all events;
- socket ones from threads
- events from code watching the filesystems
- custom GUI events from the UI. (so no 1:1 windows msg: event equivalence)

however the actions of statemachine mostly don't require sending messages
back to the threads now. The main thread can handle them.

Is this really a good idea ? By that all those events a serialized even
if they are used by completely independent threads and they are
serialized with the GUI events that can take loooooong. I _suppose_ in
Windows a thread can handle a socket independently. (I used Indi to
create a thread for each server socket, I seem to remember that they
work even if the main thread is blocked by a GUI event or a "sleep".) In
Linux sockets are blocking anyway, so it's quite necessary to use at
least one thread for each.
-Michael
 

Re:Re: Kylix now officially alive?

On 2004-12-29, Michael Schnell < XXXX@XXXXX.COM >wrote:
Quote
>- socket ones from threads
>- events from code watching the filesystems
>- custom GUI events from the UI. (so no 1:1 windows msg: event equivalence)
>
>however the actions of statemachine mostly don't require sending messages
>back to the threads now. The main thread can handle them.
>

Is this really a good idea ? By that all those events a serialized even
if they are used by completely independent threads and they are
serialized with the GUI events that can take loooooong.
Indeed. But since nearly every action has to lock the global domainobjects
(persistant objects) anyway, this doesn't matter. The longest query (search
through all 6 million objects without indexes costs 1.5-3 sec with D6.
Faster on FPC (and probably D2005/win32) due to inline probably)
Quote
I _suppose_ in Windows a thread can handle a socket independently. (I used
Indi to create a thread for each server socket, I seem to remember that
they work even if the main thread is blocked by a GUI event or a "sleep".)
In Linux sockets are blocking anyway, so it's quite necessary to use at
least one thread for each.
Well, there is async io in Unix too, but it is less common. However this will
be some work.
Anyway, I'm already playing with socketssuites for a while. The only major
success is that I ported ICS/win32, and got most of win32 Indy to compile
but not work. (no .synchronize till now).
I'm currently trying to get Synapze ported beyond linux/x86 and win32, got
it compiling but not working on freebsd. However maybe I missed one of the
structs in the conversion.
 

Re:Re: Kylix now officially alive?

Quote
Indeed. But since nearly every action has to lock the global domainobjects
(persistant objects) anyway, this doesn't matter.
Sorry but you lost me here. What are global domainobjects (persistent
objects) ?
Quote
The longest query (search
through all 6 million objects without indexes costs 1.5-3 sec with D6.
Faster on FPC (and probably D2005/win32) due to inline probably)

Speed with a single stream of actions is not the question. What happens
if there are many time consuming GUI actions (or even worse: a single
very time consuming GUI action) going on concurrently to the sockets
work ? What if there are many sockets acting concurrently ?
I seem to remember that Indi/Windows handles this with independent
threads, but I would have to recheck to be sure.
Quote

>I _suppose_ in Windows a thread can handle a socket independently. (I used
>Indi to create a thread for each server socket, I seem to remember that
>they work even if the main thread is blocked by a GUI event or a "sleep".)
>In Linux sockets are blocking anyway, so it's quite necessary to use at
>least one thread for each.


Well, there is async io in Unix too, but it is less common. However this will
be some work.

You lost me again ;) . In Unix I would suppose you just use a thread or
a process that blocks on a socket read or waiting for a connection and
handles this socket independently from other activities. Maybe it would
communicate with other parts of the application via another socket.
Quote
Anyway, I'm already playing with socketssuites for a while.
Is that what Indi/Windows offers to have an application provide
multiple server sockets with a threads for each connection established ?
Quote
The only major
success is that I ported ICS/win32, and got most of win32 Indy to compile
but not work. (no .synchronize till now).

I'm not a friend of TThread.Synchronize (even if I requested it for
porting purpose :) ). I don't like the blocking behavior of same. My
background is mostly realtime embedded stuff, so I do know that more
often than never it's important to be able to have your application do
multiple (non GUI enabled) activities at the same time as fast as it
gets. Moreover independent threads can take advantage of multiprocessor
boxes (that are getting more and more common) (and the dual-threaded
Pentium). Being able to define different priorities to the threads
sometimes is important, too, and only useful if they are really
independent from each other, avoiding unnecessary priority inversion
problems.
Quote
I'm currently trying to get Synapze ported beyond linux/x86 and win32, got
it compiling but not working on freebsd. However maybe I missed one of the
structs in the conversion.

Lost again. I feel did read about Synapse, but I'm not up to speed here.
-Michael
 

Re:Re: Kylix now officially alive?

On 2004-12-30, Michael Schnell < XXXX@XXXXX.COM >wrote:
Quote
>Indeed. But since nearly every action has to lock the global domainobjects
>(persistant objects) anyway, this doesn't matter.

Sorry but you lost me here. What are global domainobjects (persistent
objects) ?
Domainobjects is something out of the patterns world. Roughly business
data objects based on one ancestor object.
I just have more or less a hierarchy these of objects in memory, as a kind
of OOP database. The objects live on the server, and are persistant via a
streaming/logging/snapshotting system, and share some other global methods.
Clients have caches of these.
Quote
>The longest query (search
>through all 6 million objects without indexes costs 1.5-3 sec with D6.
>Faster on FPC (and probably D2005/win32) due to inline probably)

Speed with a single stream of actions is not the question. What happens
if there are many time consuming GUI actions (or even worse: a single
very time consuming GUI action) going on concurrently to the sockets
work ?
Server has no GUI, client no multiple connections.
Quote
What if there are many sockets acting concurrently ?
That's a problem in theory. However the chance on such a big one is already
very low, let alone multiple combined, since the largest queries require
global access, so they can be done only by an administrator anyway.
(customers only have permission on their little part of the object model)
Quote
I seem to remember that Indi/Windows handles this with independent
threads, but I would have to recheck to be sure.
Indy9 only has one connection/thread, and no other way. That is quite nice
for some things, but scales bad, and one of the things that changed in 10
afaik.
Quote
>>they work even if the main thread is blocked by a GUI event or a "sleep".)
>>In Linux sockets are blocking anyway, so it's quite necessary to use at
>>least one thread for each.
>
>
>Well, there is async io in Unix too, but it is less common. However this will
>be some work.

You lost me again ;) . In Unix I would suppose you just use a thread or
a process that blocks on a socket read or waiting for a connection and
handles this socket independently from other activities.
Yes. But there are also async routines that send you a SIGIO when data arrives.
search for aio_ routines. However I don't know much about it. If I'm at home again,
I'll look in stevens, and see if he has more to say about the matter.
Quote
>Anyway, I'm already playing with socketssuites for a while.

Is that what Indi/Windows offers to have an application provide
multiple server sockets with a threads for each connection established ?
I've mostly being playing on Windows till now. Slowly moving towards *nix
though. Synapze (see below) is the first.
Quote
>The only major
>success is that I ported ICS/win32, and got most of win32 Indy to compile
>but not work. (no .synchronize till now).
I'm not a friend of TThread.Synchronize (even if I requested it for
porting purpose :) ). I don't like the blocking behavior of same. My
background is mostly realtime embedded stuff, so I do know that more
often than never it's important to be able to have your application do
multiple (non GUI enabled) activities at the same time as fast as it
gets.
Threading has quite some overhead. Specially if threads only run for short
times before blocking again. So this is not so ideal as it looks at first.
A lot of realtime stuff is not threaded.
Quote
Moreover independent threads can take advantage of multiprocessor boxes
(that are getting more and more common) (and the dual-threaded
Pentium).
Sure. But then you have to have real processes that eat cpu time that can
happen in paralel. Or GC overhead to stuff somewhere.
However typically all threads access some central resource. Then you have
the choice to finely grained locks inside that resource, or global (giant-)
lock that.
However finely grained locks are expensive and complex.
If such a pattern exist that already effectively serialises the system, threading
has no real benefit if you keep your actions short
Quote
>I'm currently trying to get Synapze ported beyond linux/x86 and win32, got
>it compiling but not working on freebsd. However maybe I missed one of the
>structs in the conversion.
Lost again. I feel did read about Synapse, but I'm not up to speed here.
Just another ICS/Indy.
www.ararat.cz/synapse/
 

Re:Re: Kylix now officially alive?

Quote

Server has no GUI, client no multiple connections.

Either of GUI or a multiple connection situation could stall the work on
a request or thread when the parts are not decently decoupled.
Quote

That's a problem in theory. However the chance on such a big one is already
very low, let alone multiple combined, since the largest queries require
global access, so they can be done only by an administrator anyway.
(customers only have permission on their little part of the object model)

Here I disagree. I.e. an Indy workalike needs to be able to create a
decent HTTP server. This would handle thousands of concurrent requests.
And a request could result in a database lookup or whatever time
consuming activity. Here timesharing and multiprocessing between the
threads is really essential to keep other connections running.
Quote
Threading has quite some overhead. Specially if threads only run for short
times before blocking again. So this is not so ideal as it looks at first.

A lot of realtime stuff is not threaded.

Right you are.
Since some days I am thinking about a related chapter in a book that I
just started to write an am considering to try to publish later this
year. The book is supposed to be on "embedded communication" and the
chapter is on "Multitasking vs. 'run to completion objects' ".
In Delphi language we have both concepts: Multitasking via TThreads and
"run to completion objects" via events. So we are very free here. But
when designing an embedded device from scratch, you need to decide if
you want to implement a multitasking OS of some kind. Of course
multitasking needs much more resources (e.g. memory for the stacks) and
it's not easy to do the inter process communication and the necessary
locking decently. But OTOH if no MT is used, it's not easy to keep the
run to completion code short short enough, you don't have priories.
Moreover with MT you can write code more "straight forward", as you are
allowed to wait for (e.g. hardware) result in midst your actions.
BTW.: I understand that you read German well enough. Would you be
inclined to do some proof-reading of the stuff _if_ the book projects
really gets up to speed ?
Re.: TThread implementation and extensions in FP / Lazarus, please let
me know it I can be of any help.
P.S.: Perhaps we should move the discussion to some more appropriate
newsgroup.
-Michael
 

Re:Re: Kylix now officially alive?

Quote
>What about signals?

Since the
event would typically put data in fields of the thread, and you can't
protect that with a simple criticalsection, since if the thread doesn't run,
and deadlock would occur
Maybe signals can be used to create a message queue in user space.
To protect the pointers, the signal would need to be blocked for some
instructions when the top queue entry is taken from the FiFo queue. I
don't know if that does any harm to the receiving and/or sending thread.
I also don't know how a signal can be used to wake up a sleeping thread,
but I suppose this is possible.
As there are Signals implemented in the Posix Thread Library, they
supposedly will work together with the NPTL thread implementation.
-Michael