Re: Is threading the right solution for this challenge?
Re: Is threading the right solution for this
challenge?
Source: http://coding.derkeiler.com/Archive/Cobol/comp.lang.cobol/2006−05/msg00148.html
• From: "Chris"
• Date: 5 May 2006 08:45:51 −0700
Hi Jimmy.
Sorry − maybe if I had laid out more clearly what I was trying to do it
would have been easier to understand the "requirements."
Let me clarify here:
What I am trying to do is construct a monitoring utility for my
application in much the same vein as a UNIX utility like top or glance.
My overall application is running several (upwards of 50 right now)
processes in the background that should, under ideal conditions, be
constantly processing data. The only drawback is that it's hard
sometimes for the end−users to tell if a background process is doing
its job. This new utility will provide a way for an end−user to inspect
the processes to ensure that each one is performing and running as
expected.
The "display" thread that I mentioned will inspect the system to see
which background processes are running and which aren't (the list of
all processes are stored in a database table). When it identifies a
running process, it will call the OS to get information about the
process (memory usage, CPU consumption, etc). It will also make a
customized call to a data monitor program, which will report the number
of outstanding records to be handled by that process.
The "accept" thread will handle user requests, such as; start process,
stop process, heartbeat, up/down, page up/down, exit, etc.
Addressing Richard's concern:
The CPU will not cycle out of control on the display thread, as I will
obviously need to have some sort of sleep/delay mechanism in there.
More likely than not this will be a user defined parameter (much the
same as glance takes a parameter for it's sleep interval).
I also thought of the summary table concept last night while trying to
Re: Is threading the right solution for this challenge? 1
Re: Is threading the right solution for this challenge?
figure out the true "best approach" for this challenge. I could easily
use the DBMS_ALERT package that Oracle provides to make updates to this
summary table. Then, using that table (containing all of the items on
the screen), a refresh after an ACCEPT ... WITH TIMEOUT would be fairly
fast and I could avoid threads. The problem there is that I am relying
on one of the background jobs to be running itself, and I was hoping to
avoid that.
I have had some problems with the display in one thread and an accept
in the other, so I'll need to iron that wrinkle out. But otherwise,
I've found that working with the thread logic is not that bad.
Also − from the technical standpoint − I do not have the luxury of
Dialog System or anything of that sort. This is strictly a character
based UI − the only available commands are display and accept.
Again − thanks to everyone for the input − always good to get feedback
from folks with a similar background.
Chris
James J. Gavan wrote:
Oliver Wong wrote:
Oliver, not sure he is asking the question that you supplied an answer
to :−).
I had a helluva job finding TIMEOUT − looked at the overall index for
the N/E 4.0 on−line manuals and found following :−
http://supportline.microfocus.com/supportline/documentation/books/nx40/nx40indx.htm
So very often people ask a question here framed in a way that they
understand, 'cos they know what they want to do − so they get answers
based on what the reader interprets.
So The originator asks, "I've got a cart with a donkey which has a HUGE
rock in the back. How do I get the donkey to move ?".
They get answers like "Entice the donkey with a carrot", or perhaps,
"Prod a stick up its arse !".
But it turns out the originator has a solution for getting the donkey to
move forwards. What he is really asking is "How can I get the donkey to
go into reverse until I reach a cliff top so that I can tip the rock
Re: Is threading the right solution for this challenge? 2
Re: Is threading the right solution for this challenge?
into the sea below !". (Naturally, he gets the donkey from out between
the shafts before tipping the cart).
Net Express GUI classes allow "wantAllKeys" for a dialog; then on an
event you go to a callback to check keystrokes. But Chris is in Unix −
purely a (text) Character Mode display. (Might be a bit tricky for him
to try mixing DOS/Unix−type Screen Section with OO events, in any language).
He has two choices coding programatically :−
ACCEPT Customer−Screen (all the screen fields making up the displayed
record, automatically moving between the fields based on terminating
with the key); OR
ACCEPT Customer−Account−Number (one specific field).
Now within the Screen Section/Panels that he is using there are various
ways of terminating fields, and recognizing keystrokes or Function Keys
− much too much to absorb in a quick read − I'm assuming Chris has
checked out the On−line manuals on Character Handling.
My question to Chris − care to elaborate on why you need to keep
refreshing the screen. (No doubt you have a good reason − but I'd like
to know what it is). Using GUIs I only refresh screen when there is a
CHANGE to say a Listbox or Treeview. One exception with Treeview − no
changes and user clicks on the {−} or {+} appearing before Treeview
Labels − based on the event you expand/contract the Treeview and then
re−display.
I'm trying to establish if you want the donkey to go forwards or into
reverse :−).
Jimmy
"Chris" wrote in message
news:1146500082.954862.255300@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Compiler: MF SE 4.2 SP2
Platform: HP−UX 11i
Challenge: Have a continually refreshing display screen that
also
responds to user input.
I had been considering using ACCEPT with a TIMEOUT
clause and
refreshing after each time out, but that does not seem to be
Re: Is threading the right solution for this challenge? 3
Re: Is threading the right solution for this challenge?
the
optimal solution here. In theory, this would give me a
sluggish
application. Either the user would be waiting on the
compilation of
display data, or the display would become "stale" while
processing user
input.
I'm thinking that this is a prime candidate for me to tackle
my first
threaded application. I figure I can run the user input
interface in
one thread, whil running the continually updating output
display in
another thread.
I don't have much COBOL experience, but the functionality you're
referring to is commonly seen in games (e.g. update the screen, check if
the user entered any input, and if so process it; either way, update the
screen again and repeat). Usually in game development, you want to avoid
threads where ever possible (an exception might be heavy duty 3D
graphics processing, which I don't think applies to your case), as they
tend to just add complexity without bringing too much benefit.
In ACCEPT with TIMEOUT, what happens if the user was in the process
of entering data, and then the timeout occurs? Do you get the data that
the user half−submitted, or do you get nothing? If it's the former, you
could probably use ACCEPT with TIMEOUT, with a very low timeout (e.g.
1/100th of a second?), and just capture 1 character a time, constructing
the full string of the user's input manually. If it's the latter, you
might want to look into hooking into a library or API written in another
language to provide you with the facility to capture characters one a
time. See for example the "getch() function with no−delay" at
http://www.mkssoftware.com/docs/man3/curs_getch.3.asp
Since I have ZERO experience in this arena, I wanted to
throw it out
there for the masses and see what everyone thought.
In the meantime I'll be wading through the MF
documentation on writing
threaded applications and try to discern what I can. What is
the
typical method when designing a threaded application? Do I
start by
creating the two individual applications and then work
Re: Is threading the right solution for this challenge? 4
Re: Is threading the right solution for this challenge?
toward linking
them together, or are there other considerations?
There are many considerations when writing multithreaded code, and
it's one of those things that's hard to get right. Code like:
MOVE 3 TO A
DISPLAY A
might not yield the output 3, if another thread has stepped in an
modified the contents of A in between those two lines. There are
techniques and data structures specifically designed for use in
multithreaded programming (e.g. mutex, condition variable, locks, etc.),
and entire books on writing multithreaded applications within a given
programming language.
You might want to start at
http://users.actcom.co.il/~choo/lupg/tutorials/multi−thread/multi−thread.html
and work from there.
− Oliver
.
Re: Is threading the right solution for this challenge? 5