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 operating system vary from platform to platform, but simply decideing to ignore IPC (much less I/O) is throwing the baby out with the bathwater, and it absolutely does hurt the commercial viability of any product that implements the standard. If you don't care about portability and are willing to accept vendor lock-in, that's fine. But do you really want an EHR system that is tied to a single platform?
--- "K.S. Bhaskar" <[EMAIL PROTECTED]> wrote: > 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 > done > with M code. > > One of the benefits of deploying a server under [x]inetd is that the > process goes away when the client disconnects, and nothing needs to > be > done to shut it down, either by having it poll for a message or > handle > an asynchronous signal. > > -- Bhaskar > > On Fri, 2005-07-29 at 12:27 -0500, Greg Woodhouse wrote: > > 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 polling technique to determine if they > > should > > stop. But this is problematic, too. for one thing, 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 throttle this process > > back > > enough so that it consumes only a small percentage of processing > time > > (and, potentially, direct I/O). > > > > Now, asynchronous delivery of signals (a perfect job for SSVNs, > IMO) > > is > > a much more efficient (and typical) way of solving the same > problem. > > Certainly, if I were to code a solution to this problem in C, I > would > > not rely on a mechanism so primitive as a polling loop. > > <soapbox>This is yet another reason I continue to argue that the > > language standard needs to be updated.</soapbox> > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration > Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Hardhats-members mailing list > Hardhats-members@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/hardhats-members > === Gregory Woodhouse <[EMAIL PROTECTED]> "Design quality doesn't ensure success, but design failure can ensure failure." --Kent Beck ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
