Does anybody know whether Prf* routines are usable from inside a
window proc? Do they block or violate the 1/10s rule in any
other way?
Does anybody know whether Prf* routines are usable from inside a window proc? Do they block or violate the 1/10s rule in any
other way?
What's the "1/10's rule"? TIA and TTYL.
What's the "1/10's rule"? TIA and TTYL.
A window procedure which is run while PM is waiting is supposed to
return control within 1/10th of a second, so that the system
response doesn't suffer. Anything that takes more than that period
of time to accomplish should be done on a second thread.
Does anybody know whether Prf* routines are usable from
inside a
window proc? Do they block or violate the 1/10s rule in any
other way?
What's the "1/10's rule"? TIA and TTYL.
Some senseless babbling from Vitus Jensen to Coridon Henshaw
on 06-08-00 00:43 about Using Prf* routines in wi...
[snip]
But even if the user selected a network drive it would hang the
PM if the network fails and my program uses
PrfWriteProfileData() from WM_MOVE.
In my book, any function which can potentially block for an
indefinite amount of time belongs in a second thread.
So, instead of calling the Prf*() functions from your window
procedure, create a wrapper for all the functions you need, which
call the API's on a second thread (I recommend a wrapper simply
to avoid clutter in the window procedure).
What's the "1/10's rule"? TIA and TTYL.
What's "TIA" and "TTYL"?
The "1/10's rule" is a rule of thumb when it comes to presentation
manager programming. It says that your window procedure should
return within 0.1s to keep the user interface responsive.
The chosen interval comes from ancient ages when a 80486DX33 was a
fast processor (and everyone used to those speeds) so today the rule
should be formulated a little different. Let's try it:
"You should not spend a considerable amount of time inside the
window procedure. Don't use APIs which may block (as the duration
of the block is not predictable in a multitasking system), don't
access files or devices (access may fail and have a long timeout),
and don't do lengthy operations (like filling a large listbox)."
"You should not spend a considerable amount of time inside the
window procedure. Don't use APIs which may block (as the duration
of the block is not predictable in a multitasking system), don't
access files or devices (access may fail and have a long timeout),
and don't do lengthy operations (like filling a large listbox)."
I've seen that kind of stuff mentioned before. And this is why all of those functions should be relegated to threads? So, really when you
look at it, in nearly all cases the window procedure is little more
than a thread dispatcher, which is why you want to try to keep it
clear. Is that about right?
"Thanks In Advance" and "Talk To You Later". [:)What's the "1/10's rule"? TIA and TTYL.What's "TIA" and "TTYL"?
The "1/10's rule" is a rule of thumb when it comes to presentation
manager programming. It says that your window procedure should
return within 0.1s to keep the user interface responsive.
The chosen interval comes from ancient ages when a 80486DX33 was
a fast processor (and everyone used to those speeds) so today the
rule should be formulated a little different. Let's try it:
"You should not spend a considerable amount of time inside the
window procedure. Don't use APIs which may block (as the
duration of the block is not predictable in a multitasking
system), don't access files or devices (access may fail and have
a long timeout), and don't do lengthy operations (like filling a
large listbox)."
I've seen that kind of stuff mentioned before. And this is why
all of those functions should be relegated to threads? So, really
when you look at it, in nearly all cases the window procedure is
little more than a thread dispatcher, which is why you want to
try to keep it clear. Is that about right?
Sort of. The window procedure should do everything necessary to
maintain the window itself, short of long paints (which should be
done on a separate thread), and dispatch threads for the real work. Ideally, that is.
One way of making that easier is to set up a second message queue,
that doesn't have a window associated with it, which receives all
messages from the main window procedure via WinPostMsg() that aren't
to be done in that main procedure.
Sorry for the lengthy delay. My host was down for a couple of weeks,
then I got busy here in the shop and in my personal life.
Sort of. The window procedure should do everything necessary to
maintain the window itself, short of long paints (which should be
done on a separate thread), and dispatch threads for the real work. Ideally, that is.
One way of making that easier is to set up a second message queue,
that doesn't have a window associated with it, which receives all
messages from the main window procedure via WinPostMsg() that aren't
to be done in that main procedure.
That would also require its own thread to process the messages on the second queue? Would I be correct in understanding that this is just a "technique" thing, something that you would do just to give the
program more structure so that it behaves in a more logical fashion,
but which does not really benefit the user of the program in a
noticeable or practical way? (I'm not trying to sound critical here,
just trying to understand where the suggestion is coming from.)
| Sysop: | digital man |
|---|---|
| Location: | Riverside County, California |
| Users: | 1,029 |
| Nodes: | 17 (1 / 16) |
| Uptime: | 93:45:44 |
| Calls: | 504,191 |
| Calls today: | 13 |
| Files: | 155,742 |
| D/L today: |
94,315 files (20,045M bytes) |
| Messages: | 446,446 |
| Posted today: | 6 |