Okay, just one more response. When you get right down to it, the
point I was trying to make is that polling in basically I/O (even if
the device you are reading is shared memory) and I/O is expensive,
much more so than most people (including programmers) realize. The
nice thing about
Sent: Friday, July 29, 2005 10:30 PM
Subject: Re: [Hardhats-members] Changeing/Activating PORT 9200 on the
VistaLinuxServer
This is what I would have expected, at least on any systems where
MUMPS jobs are implemented as native threads or processes, but not
that many years ago, I've heard
On 7/29/05, Nancy Anthracite [EMAIL PROTECTED] wrote:
D ^ZTMB
then D ^ZTMON and keep hitting enter or wait about 2 minutes for the main
loop
D STRT^XWBTCP(9200)
To shut down, first do
D STOP^XWBTCP(9200)
then
D STOP^ZTMKU
Select OPTION: 5 INQUIRE TO FILE ENTRIES
Ok, done the following mentioned in
http://www.hardhats.org/projects/VistA_Install/CPRSStart12.html:
1. At the VISTA prompt, enter D ^ZTMB to start TaskMan
2. Then start BROKER listening on port 9210 by entering the following
at the VISTA prompt: D STRT^XWBTCP(9210) You may choose another port
Have you got anything listed in that RPC Broker Site Parameters file as a
listener? If you do, use that one. IF not, it will be created when you do
he D START^XWBTCP(PORT NUMBER)
On Friday 29 July 2005 12:29 pm, Zeno Davatz wrote:
On 7/29/05, Nancy Anthracite [EMAIL PROTECTED] wrote:
D
Look in netstat to see if it is listening.
On Friday 29 July 2005 12:35 pm, Zeno Davatz wrote:
Ok, done the following mentioned in
http://www.hardhats.org/projects/VistA_Install/CPRSStart12.html:
1. At the VISTA prompt, enter D ^ZTMB to start TaskMan
2. Then start BROKER listening on port
Also, bear in mind that starting and stopping background processes in
VistA is not instantaneous. Unfortunately, standard MUMPS doesn't
providwe support for mechanisms like FIFOs or even signals.
Unfortunately, this means that it is necessary for background processes
to implement some kind of
On 7/29/05, Nancy Anthracite [EMAIL PROTECTED] wrote:
Have you got anything listed in that RPC Broker Site Parameters file as a
listener? If you do, use that one. IF not, it will be created when you do
he D START^XWBTCP(PORT NUMBER)
I'm doing exactly this:
GTMD STRT^XWBTCP(9200)
Start TCP
Greg --
Since IO is implementation dependent, standard MUMPS does not say
anything that I am aware of about supporting or not supporting named
pipes (FIFOs).
Note that GT.M does support IO to FIFOs and does have a means for an M
process to handle an asynchronous interrupt (SIGUSR1), and it's all
I know that's the party line, but it's just not good enough. System
dependencies or no, it is crucial to provide suitable abstractions for
both I/O and intetprocess communications on any platform. A purist may
(perhaps even rightly) argue that the abstractions providided by the
underlying
Gregory Woodhouse wrote:
it is all too easy
to write a process that spends a significant amount of its time
actually polling globals for a stop flag or something similar. If
this is done thoughtlessly, it can bring a system to its knees, and any
practical implementation is going to have to
This is what I would have expected, at least on any systems where
MUMPS jobs are implemented as native threads or processes, but not
that many years ago, I've heard that people have reported finding
otherwise. But be that as it may, yielding the processor isn't the
only issue. You still
12 matches
Mail list logo
