 |
BorlandTalk.com
Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
David Reeve
Guest
|
 Posted: Wed Nov 12, 2003 11:23 am Post subject: task scheduling under 2K ..... COM problem |
 |
|
For the last few weeks I've been chasing through hardware and software to
pin down an intermittent failure in our new data acquisition system. It's
hideously complicated, but have finally shown it to be an effect of task
loading in W2K on an out-of-process COM server.
The simplified situation is as follows....
a) Server is a freestanding exe using single threaded apartment model. The
procedures exposed by the interface aren't particularly heavy on the CPU.
b) Client uses a timer to fire off a bunch of 60 or so consecutive calls to
the server every 1000ms or so, and we grab the tickcount taken to achieve
this.
When the OS is unloaded, this burst of calls to the server is taking
something like10msec. However, if I then launch a CPUSoaker (app sitting in
forever loop) the time taken per burst jumps to a figure of typically 1.7
sec or 2.4 sec and sometimes even higher, eg 9.8 secs.
Note that this is sudden event, not a gradual one. It doesn't require a
100% soaker to be running. The client is completely clobbered and can't
manage to paint itself. The server runs quite happily and will respond to
windows messages like resize etc, but just takes it's time working through
the 60 or so calls at a drastically reduced rate. So in normal practice what
we have is a situation where the system will run perfectly for days,
inexplicably throw a bunch of communication errors for minutes on end,
recover itself and then continue running impeccably.
My knowledge of the inner workings of COM is pretty poor, so any comments
or suggestions greatfully received.
Dave
|
|
| Back to top |
|
 |
David Reeve
Guest
|
| Posted: Sun Nov 16, 2003 12:17 pm Post subject: Re: task scheduling under 2K ..... COM problem |
|
|
David Reeve" <dree4456 (AT) big-pond (DOT) net.au> wrote
For anyone who might be interested, I have found a solution to my problem,
and have a 'sort-of' explanation for what is going on.
What I think should happen......
Lets assume for the moment that the client process, server process and cpu
soaker process are running all with the same priority. The client, when it
calls the server puts a message into the server's queue and yields.
Depending which was the last to get a time quantum, either cpu soaker or the
server will run next. When the server runs, it will need to return to its
message loop and then dispatch the waiting procedure call. Thus the server
and the cpu soaker will load share until the procedure is done. The client,
meanwhile, will be 'frozen'. For very short procedure calls, we should see a
return in one or two time quanta.
What seems to happen.....
a) If cpu soaker is not present we find the procedure returns in 1 to 2
quanta, as would be expected.
b) If cpu soaker is the foreground app, its priority is boosted, and thus
one would expect it to get a disproportionate amount of cpu while there is
competitiion between it and the server. In fact, it soaks *all* the cpu, and
return times extend out to to 1.4 sec (approx 100 quanta) and beyond.
c) If the client is the foreground process, the return times are reduced to
approx 30 quanta. Why? Surely the client is suspended until the server gets
done. Does making the client the foreground process also boost the server
process?
d) If the server is made the foreground process, the return times are
likewise 30 quanta. This partial improvement is hard to understand. If the
server is boosted to a priority above the cpu soaker, we should see it take
a disproportionate amount of CPU. This it does not.
e) If we set the client process priority to high, we get a repeat of c)
provided the client is in the foreground, and if instead we set the
priority of the server to high we get a repeat of d) provided the server is
in the foreground. However, if we set *both* client and server to high
priority, suddenly everthing works just fine with return times of 1 to 2
quanta.
Now comes another strange thing. The load sharing with both client and
server processes running at high priority seems impeccable. This includes
what happens when you open a few more cpu soakers, plus Word, Excel and any
other app I could manage to click on. The only reason I didn't try this
straight-off was that all my instincts told me this would be a bad idea. The
only possible explantion I can offer is that both client and server are
simply I/O building blocks. In spite of the fact they may be carrying out
thousands of transactions a second, each transaction is actually quite brief
and they spend most of their time idling. If you did this with a cpu
intensive app, I suspect it would be impossible to run any other apps.
Dave
|
|
| Back to top |
|
|
J French
Guest
|
| Posted: Sun Nov 16, 2003 1:51 pm Post subject: Re: task scheduling under 2K ..... COM problem |
|
|
On Sun, 16 Nov 2003 12:17:35 GMT, "David Reeve"
<dree4456 (AT) big-pond (DOT) net.au> wrote:
| Quote: | David Reeve" <dree4456 (AT) big-pond (DOT) net.au> wrote in message
news:dLosb.8196$aT.214 (AT) news-server (DOT) bigpond.net.au...
For anyone who might be interested, I have found a solution to my problem,
and have a 'sort-of' explanation for what is going on.
snip |
I am no expert on how COM is implemented
However one or two things rang bells in your first post
AFAIK the Client communicates with the Server via the Message barrier
(literally SendMessage - not even PostMessage)
- I like to think of the Message system as a form of membrane for
controlled osmosis
Certain messages like the paint ones, 'naturally' have a much higher
priority - somehow they seem to queue jump
Other messages like the ones 'created' by the Client and despatched to
the Server have a much lower 'natural' priority
Whatever is the foreground App 'naturally' gets more attention from
Windows
- if it is your CPU soaker, *that* is starving both your Client and
the Server of attention
In your setup, with the Soaker in the foreground
- there are two 'inter-related' threads communicating with each other
- and both are being starved
When you load up other CPU soakers, only one can have 'Momma's'
priority attention - the one in the foreground
Personally I would be inclined to be brutal and use :-
SetThreadPriority and/or SetThreadPriorityBoost
That, or remove all other Apps from the system
I reckon that Thread priority is 'inherited' from the Client, so I
would be inclined to set the Client up with THREAD_PRIORITY_HIGHEST
I think, but am not sure, that under the NT+ stuff an App has enough
rights to do this to itself without having to leap through burning
hoops.
My guess is that the Priority stuff was designed in by MS to overcome
just such situations
|
|
| Back to top |
|
|
David Reeve
Guest
|
| Posted: Mon Nov 17, 2003 7:58 am Post subject: Re: task scheduling under 2K ..... COM problem |
|
|
"J French" <erewhon (AT) nowhere (DOT) com> wrote
| Quote: | On Sun, 16 Nov 2003 12:17:35 GMT, "David Reeve"
|
[snip]
Thanks for the comments Jerry.
| Quote: |
SetThreadPriority and/or SetThreadPriorityBoost
|
Initially I tried boosting the priority of the slave thread communicating
with the server, but saw no real result. However, this was earlier in my
floundering about. When I had finally chopped things down to just what was
needed to reproduce the behaviour, I then settled for setting the priorty of
the entire app, as I had multiple apps to consider.
| Quote: | That, or remove all other Apps from the system
|
Yep, this what we normally do...... customer is forbidden to run any other
program whilst data acquisition is in progress. However, in this particular
case, we have our own large GUI based program that communicates with the
client, also by COM but at a much lower rate. Depending upon quite what is
happening at the time, this program can represent a substantial cpu load,
and was apparantly starving the client-server pair.
| Quote: | I reckon that Thread priority is 'inherited' from the Client, so I
would be inclined to set the Client up with THREAD_PRIORITY_HIGHEST
I suspect this is the case, but am yet to find documentation. |
| Quote: | I think, but am not sure, that under the NT+ stuff an App has enough
rights to do this to itself without having to leap through burning
hoops.
|
Load sharing under W2K is always pretty impressive with this one exception.
COM is such an integral part of the MS game plan, I find it hard to believe
that they haven't allowed for it's impact on load sharing. I hadn't really
thought about it before, but you can see that load sharing a group of
independent apps is one thing, but having their processor demands
interlinked is going to make life substantially more complex for the OS.
| Quote: | My guess is that the Priority stuff was designed in by MS to overcome
just such situations
|
Could be.... saved my bacon at any rate.
Dave
|
|
| Back to top |
|
|
J French
Guest
|
| Posted: Mon Nov 17, 2003 11:54 am Post subject: Re: task scheduling under 2K ..... COM problem |
|
|
On Mon, 17 Nov 2003 09:43:51 +0100, "Bjørge Sæther"
<bjorge (AT) hahaha_itte (DOT) no> wrote:
<snip>
| Quote: | Certain messages like the paint ones, 'naturally' have a much higher
priority - somehow they seem to queue jump
Mouse / Keyboard messages have high priority. An app that's about to avoid
mouse cursor to be updated needs to consume 100% cpu time.
Paint messages have the lowest priority of all, actually. It's handled in a
separate queue, and paint messages are even "merged" before processed. That
is, if two paint messages addressed to the same window are put in queue, one
of them is simply discarded. This is used when writing code involving window
painting; You don't care to register whether there has allready been
"booked" a repaint before you invalidate a window(protion). The following
code would end up in *one* paint message:
|
<snip>
Thanks - I've never had it all pinned down
The Paint priority would explain
<quote>
The PeekMessage function normally does not remove WM_PAINT messages
from the queue.
<quote>
Do you reckon an AX EXE 'inherits' the Client's thread priority ?
I do remember stuff about boosting the priority of the foreground App
.... somewhere in the system configuration
But it does strike me that it is probably better to do it internally
from within code. Probably as a config option
|
|
| Back to top |
|
|
David Reeve
Guest
|
| Posted: Tue Nov 18, 2003 7:07 am Post subject: Re: task scheduling under 2K ..... COM problem |
|
|
"Bjørge Sæther" <bjorge (AT) hahaha_itte (DOT) no> wrote
[snip]
Thanks for the comments...
| Quote: | b) If cpu soaker is the foreground app, its priority is boosted, and
thus
one would expect it to get a disproportionate amount of cpu while there
is
competitiion between it and the server. In fact, it soaks *all* the cpu,
and
return times extend out to to 1.4 sec (approx 100 quanta) and beyond.
I didn't quite get this, but is it so that all of the client's work
happens
winhin *one* timer event ?
|
The details are a bit complicated, but yes, once a timer event is fired, the
client needs to grab some data (involving maybe 1000 calls to the server)
and return in a reasonable time frame. 10msec or so is absolutely fine,
400msec is not. We are sampling from a mechanically rotating device, and
will be overrun by the next sample slot if we take too long!
| Quote: |
I don't know what's to be expected; as those applications are doing very
different things. The cpu soaker does excactly what it sounds like, it
attempts to run as many lines of code as possible. Every time it's
scheduled, it has instructions to run continously until abrupted again by
the scheduler. It will *allways* utilize 100% of the time it possibly
gets.
The client/server pair uses messages to communicate - this means that they
inadvertedly loose cpu time whenever they have nothing to do *right now*
when scheduled.
|
I think this is what happens when the client calls the server and waits for
it to return. My understanding is that calls to an out-of-process server are
asynchronous, and multiple clients queue their requests to the message
queue. However, your and Jerry's point about relative priorities within the
queue is one I hadn't allowed for. I am going to have to do more reading...
| Quote: | There is nothing in Windows assuring that apps get a fair amount of cpu
time. It's simply so that every time the scheduler is to reschedule tasks
/
threads (some 50 times / sec), it runs the "next one" in the queue.
Regardless of whether this was getting the previous 1,000,000 time slice
or
not.
|
I think W2K is smarter than this. My reading is that there is a queue
maintained for every one of the 32 priorities (or at least the 16
reassignable priorities.... I can't quite remember) With each tick, the
scheduler works down the queues looking for a process that is runnable.
Within any one queue, if two processes are runnable, the one that has been
waiting to run the longest gets the time slice.
So - you need to find out why your client/server apps aren't scheduled
| Quote: | as often as your soaker. The explaination is simple, I believe; The soaker
has got a priority a little above the others, and never yields spare time
for other apps to run. I believe it would change dramatically if the
soaker
did a sleep(0); call every now and then. That's what most applications
do -
deliberately give away time slices all the time.
|
Certainly a sleep(0) would change things, and I take your point that
cpuSoaker is not a good windows citizen, but the point is that with W2K it
is very rare to find an app that is impacted by cpuSoaker. All other apps I
could quickly lay my hands on, and some of these are seriously cpu
intensive, load share with cpuSoaker. It's not that I intend to load the
system in this arbitary way, rather the problem is that my main GUI software
which talks to the client server acquisition system can present a
substantial cpu load from time to time. I can't have the possibility of a
sudden surge in cpu utilization knocking out the data acquisition system.
| Quote: |
Also, the client application uses a timer - which has low priority.
|
This is not such a problem. Its what happens once a tick is being processed
that concerns me.
Dave
|
|
| Back to top |
|
|
J French
Guest
|
| Posted: Tue Nov 18, 2003 12:00 pm Post subject: Re: task scheduling under 2K ..... COM problem |
|
|
On Tue, 18 Nov 2003 09:00:37 +0100, "Bjørge Sæther"
<bjorge (AT) hahaha_itte (DOT) no> wrote:
<snip>
| Quote: |
OK. Then you'll have to have a go at early binding and a type library, if
you haven't allready done so.
|
Alternatively, maybe, get rid of the whole COM overhead and simply use
SendMessage
|
|
| Back to top |
|
|
David Reeve
Guest
|
| Posted: Tue Nov 18, 2003 1:08 pm Post subject: Re: task scheduling under 2K ..... COM problem |
|
|
"Bjørge Sæther" <bjorge (AT) hahaha_itte (DOT) no> wrote
[snip]
| Quote: |
OK. 10ms for 1000 calls via a COM interface sounds tough.
|
 it certainly is.... we could offload a large percentage of it to a piece
of dedicated hardware, and would dearly love to, but are now a bit far down
the road to start spending resource in that direction.
| Quote: | That is, you'll
*have* to use early binding to make it. Have you imported a type library,
or
are you just writing code on OleVariant's ?
|
It early binding I'm using..... I'd hate to think what would happen with an
OleVariant!
[snip]
| Quote: | I think W2K is smarter than this. My reading is that there is a queue
maintained for every one of the 32 priorities (or at least the 16
reassignable priorities.... I can't quite remember) With each tick, the
scheduler works down the queues looking for a process that is runnable.
Within any one queue, if two processes are runnable, the one that has
been
waiting to run the longest gets the time slice.
Yes. But it's not so that it "makes up" for what has been done before
besides at any given point, run the thread that's been waiting longest. A
"queue". You can't schedule an application to take 10%, 50% or 90%. Other
multitasking/threading system has been doing this, I believe.
|
Yes that's right. You'll get the load balancing as 'it comes', but, more
often than not I see W2K doing a pretty good job of this.
| Quote: | Now, your soaker could bring *any* application to a full stop, maybe
except
from Interbase. When the latter runs a lengthy query, there is room for
little else on the machine. The question is whether you've got a chance of
making _any_ application coexist peacefully with it ?
Make a cpu soaker and try for yourself. I used, - while True do; - |
called from a button, and used task manager to kill it. W98 hates it, but
you can have it running under W2K on a reasonably powerful machine with very
little impact. See how many instances you can launch before it really starts
to hurt.
Dave
|
|
| Back to top |
|
|
David Reeve
Guest
|
| Posted: Tue Nov 18, 2003 1:15 pm Post subject: Re: task scheduling under 2K ..... COM problem |
|
|
"J French" <erewhon (AT) nowhere (DOT) com> wrote
| Quote: | On Tue, 18 Nov 2003 09:00:37 +0100, "Bjørge Sæther"
[email]bjorge (AT) hahaha_itte (DOT) no[/email]> wrote:
snip
OK. Then you'll have to have a go at early binding and a type library, if
you haven't allready done so.
Alternatively, maybe, get rid of the whole COM overhead and simply use
SendMessage
|
Before I got the trick of raising the priority to work, my last ditch stand
was going to compile the whole lot in one project, or as an intermediate
strategy, keep the servers in-process which makes them synchronous, not
unlike SendMessage as you suggest. Trouble is I'm in love with the current
architecture and really don't want to go down that route.
Dave
|
|
| Back to top |
|
|
J French
Guest
|
| Posted: Tue Nov 18, 2003 1:54 pm Post subject: Re: task scheduling under 2K ..... COM problem |
|
|
On Tue, 18 Nov 2003 13:15:56 GMT, "David Reeve"
<dree4456 (AT) big-pond (DOT) net.au> wrote:
<snip>
| Quote: | Alternatively, maybe, get rid of the whole COM overhead and simply use
SendMessage
Before I got the trick of raising the priority to work, my last ditch stand
was going to compile the whole lot in one project, or as an intermediate
strategy, keep the servers in-process which makes them synchronous, not
unlike SendMessage as you suggest. Trouble is I'm in love with the current
architecture and really don't want to go down that route.
|
I know what you mean, there is something really elegant about having a
number of totally separate components 'singing in tune'
However, if it is 'one to one' communication, then there is a pretty
good case for putting the Server in a DLL
If it is 'many clients' to one server, then (with a little work) you
could strip out all the COM stuff, yet retain the structure of the App
Perhaps I am being seditious, but my gut feeling is that all this COM
stuff is a complicated wrapper for some very simple functionality.
Another point that occurred to me (your problem is interesting) is it
possible to make your system Asynchronous ?
I gather that it is a 'machine monitoring' system, but does the
machine require instant feedback ?
- If so delete the above
I'm also inclined to Bjørge's view on hardware, it is so incredibly
cheap that one can happily have two machines rather than squeezing the
software onto one bit of kit.
|
|
| Back to top |
|
|
Martin Harvey (Demon Acco
Guest
|
| Posted: Wed Nov 19, 2003 1:23 am Post subject: Re: task scheduling under 2K ..... COM problem |
|
|
On Tue, 18 Nov 2003 07:07:02 GMT, "David Reeve"
<dree4456 (AT) big-pond (DOT) net.au> wrote:
| Quote: | The details are a bit complicated, but yes, once a timer event is fired, the
client needs to grab some data (involving maybe 1000 calls to the server)
and return in a reasonable time frame. 10msec or so is absolutely fine,
400msec is not. We are sampling from a mechanically rotating device, and
will be overrun by the next sample slot if we take too long!
|
David,
Excuse my complete non-reading of the rest of this thread, but your
little quote above has made me realise that I might be able to help,
considering that I also write embedded kit with reasonably hard
real-time demands.
In situations such as this, my advice would be to have a thread to
does the collection of the data every X milliseconds, and have that
thread do as little work as possible.
Then set the threads priority to "realtime". That's right, get it to
pre-empt *everything* else. Then make the work that it does:
- Grab the data.
- Shove it into a reasonably large ring-buffer that you lock in memory
(do not allow to be paged out). All you need to do is to make the ring
buffer big enough to deal with your maximum expected delay.
- Go back to sleep or wait on something, and don't watse any more CPU
at this priority.
With such a strategy I'd expect you to *always* be able to service
data rasonably, and if your buffer is a megabyte or so, I'd also
expect you to be able to deal with several seconds of delay on the
output side of things.
The secret with realtime multithreaded systems such as this is that if
you can't guarantee how long some proecessing will take, just allocate
buffers between the various stages of processing, size them
appropriately, and then set the thread priorities.
Since you're doing something that's hard real-time, I'd say that *is*
a situation where you can have realtime priority threads in the
system.
Now for my other question: how are you synchronising your thread with
the physical input to the machine? If you're currently polling some
device, then that won't work with a realtime priority thread (you'll
lock the system) - what you need to do in such a situation is to use
an interrupt based scheme for communicating with the hardware device.
What's the device and are you using the Win32 ASI, or sending a device
driver IOCtl calls, or what?
MH.
|
|
| Back to top |
|
|
David Reeve
Guest
|
| Posted: Wed Nov 19, 2003 6:12 am Post subject: Re: task scheduling under 2K ..... COM problem |
|
|
"J French" <erewhon (AT) nowhere (DOT) com> wrote
| Quote: | On Tue, 18 Nov 2003 13:15:56 GMT, "David Reeve"
[email]dree4456 (AT) big-pond (DOT) net.au[/email]> wrote:
[snip] |
| Quote: | However, if it is 'one to one' communication, then there is a pretty
good case for putting the Server in a DLL
If it is 'many clients' to one server, then (with a little work) you
could strip out all the COM stuff, yet retain the structure of the App
Perhaps I am being seditious, but my gut feeling is that all this COM
stuff is a complicated wrapper for some very simple functionality.
|
Yes, it does boil down to something like this. Early versions used a single
exe that directly hit the IO ports, as you can do in W98. However, there are
horrendous maintainance problems associated with allowing the hardware to
project through into the main GUI code. In particular, if there are many
different hardware flavours they all evolve down their own versioning path.
Using COM, I am able to introduce two free-standing layers of abstraction.
The first maps physical IO resources to abstract 'tags'. The second wraps
the protocol used by the actual monitoring hardware and communicates with it
using the abstract 'tags' presented by layer1. Thus changes in IO
configuration impact layer 1 only, and changes in external hardware layer2
only, while the main thrust of the software effort, the GUI which streams
data up from layer 2, is rendered completely independent of external
hardware and IO configuration. It is also an extensible scheme in that one
can add additional free standing clients at any level to share the resources
offered by the servers.
| Quote: | Another point that occurred to me (your problem is interesting) is it
possible to make your system Asynchronous ?
I gather that it is a 'machine monitoring' system, but does the
machine require instant feedback ?
- If so delete the above
|
Yes and no. By the time you get up to the GUI, things are asynchronous, but,
like in any control function, I have to have a handle on just how great the
latency might be. You might say that I'm being bitten because 20ms walking
out to over 1 sec is too great.
| Quote: |
I'm also inclined to Bjørge's view on hardware, it is so incredibly
cheap that one can happily have two machines rather than squeezing the
software onto one bit of kit.
|
Yes, this is something I would like to experiment with.
Dave
|
|
| Back to top |
|
|
David Reeve
Guest
|
| Posted: Wed Nov 19, 2003 7:09 am Post subject: Re: task scheduling under 2K ..... COM problem |
|
|
"Martin Harvey (Demon Account)" <martin (AT) pergolesi (DOT) demon.co.uk> wrote in
message news:3vglrvk41qusp45tv2covomkbu2egb74qp (AT) 4ax (DOT) com...
Thanks for the response Martin.
| Quote: | In situations such as this, my advice would be to have a thread to
does the collection of the data every X milliseconds, and have that
thread do as little work as possible.
Then set the threads priority to "realtime". That's right, get it to
pre-empt *everything* else. Then make the work that it does:
|
I've never had the 'bottle' to try 'realtime', or maybe never had an
acquisition sequence sufficiently short to do this.
| Quote: | - Grab the data.
- Shove it into a reasonably large ring-buffer that you lock in memory
(do not allow to be paged out). All you need to do is to make the ring
buffer big enough to deal with your maximum expected delay.
- Go back to sleep or wait on something, and don't watse any more CPU
at this priority.
With such a strategy I'd expect you to *always* be able to service
data rasonably, and if your buffer is a megabyte or so, I'd also
expect you to be able to deal with several seconds of delay on the
output side of things.
|
The acquisition thread pretty much does this. The real bug-bear is that
this is a polled system (for historical reasons) and thus we may have to
wait as much a 1sec for data to arrive. This is handled by putting the
thread to sleep between retries, but a single 'try' makes as many as 500
calls to a COM server, and thus is not light on cpu (see my reply to Jerry
above for the reason its done this way). Increasing the thread priority one
or two notches did little to solve the problem, but increasing the process
priority for *both* client and server restored good load balancing when the
OS was loaded with another cpu soaking app.
| Quote: |
The secret with realtime multithreaded systems such as this is that if
you can't guarantee how long some proecessing will take, just allocate
buffers between the various stages of processing, size them
appropriately, and then set the thread priorities.
Since you're doing something that's hard real-time, I'd say that *is*
a situation where you can have realtime priority threads in the
system.
Now for my other question: how are you synchronising your thread with
the physical input to the machine? If you're currently polling some
device, then that won't work with a realtime priority thread (you'll
lock the system) - what you need to do in such a situation is to use
an interrupt based scheme for communicating with the hardware device.
|
Yep couldn't agree more..... polling from the user layer down to the IO is
not being a good windows citizen.
| Quote: |
What's the device and are you using the Win32 ASI, or sending a device
driver IOCtl calls, or what?
Ultimately I'm using IOCtl to make calls into the device driver that comes |
with the digio card. Herein lies the rub. Using a standard DIO card avoids
the need to build your own dedicated interface card and device driver, but
it comes with the penalty that a whole heap of coms stuff (bumping lines
high and lo ) is shifted up to the user layer of the OS, where it really
shouldn't ought'a be. I think I'm going to have to get to grips with writing
VXDs one day. Making the PCI interface card is easy enough.
Dave
|
|
| Back to top |
|
|
J French
Guest
|
| Posted: Wed Nov 19, 2003 10:52 am Post subject: Re: task scheduling under 2K ..... COM problem |
|
|
On Wed, 19 Nov 2003 06:12:01 GMT, "David Reeve"
<dree4456 (AT) big-pond (DOT) net.au> wrote:
| Quote: |
"J French" <erewhon (AT) nowhere (DOT) com> wrote in message
news:3fba2077.187070699 (AT) news (DOT) btclick.com...
On Tue, 18 Nov 2003 13:15:56 GMT, "David Reeve"
[email]dree4456 (AT) big-pond (DOT) net.au[/email]> wrote:
[snip]
|
I follow your reasoning
There is a great deal to be said for 'layering' Apps
I would still be tempted to use DLLs
- they can be 'replaceable' using LoadLibrary
- but you know all about that
One thing that occured to me ...
You are performing the activity within a Timer Loop
.... perhaps the Timer could do a PostMessage to a custom Windows
message and exit immediately
- I have a gut instinct that this might be cleaner
Possibly due to guilt over having abused Timers in the past ....
|
|
| Back to top |
|
|
David Reeve
Guest
|
| Posted: Thu Nov 20, 2003 1:45 am Post subject: Re: task scheduling under 2K ..... COM problem |
|
|
"Bjørge Sæther" <bjorge (AT) hahaha_itte (DOT) no> wrote
[snip]
| Quote: | The main overhaed with using COM is when it's an out-of-process server.
Couldn't you use .dlls ? In that case, using a COM object isn't much
slower
than any delphi object compiled into the executable.
Yes I think that is so. I have other apps where I make extensive of |
'in-process' servers which carry substantial traffic without any problems.
Not only do you avoid the overhead of marshalling (I guess), but you are
dealing with the one process, and there should be less confusion for the OS
as occurs when you start cross-coupling processes. However, I am still in
love with the idea of breaking things into free-standing exes. For the
moment I have a fix, but always have the fall-back to an 'in-process'
server, or as Jerry points out, completely do away with COM altogether.
[snip]
| Quote: | If one does _indeed_ mean realtime, running it on a desktop computer is
risky. If a user tries e.g. burning a CD, both tasks would possibly have
diminuished chances of success :-)
|
I try to discourage users from running other software on the system....but
this doesn't mean they won't, or what's more confusing, won't admit to it.
One of the outcomes of this thread has been to make me think seriously about
the importance of not allowing even moderately cpu-intensive real-time code
up into the user space. This means, either writing a dedicated vxd to shift
a lot of the activity down to the IO layer, or using a dedicated 'black-box'
PC to carry out this functionality.
Dave
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
