> Spin ... if the open() fails because of EBUSY, > then wait some fraction of a second and try again. > Or fail immediately with a "the hypervisor is busy". > If after a wait and re-try it fails again, then fail > with the busy error message, or wait a second interval. > > This is not rocket science. > It's not elegant either, but functional.
No, imagine one of your automatic system maintenance scripts crashes for some reason. Then you have to solve the "vmcp is locked" situation manually or implement a "steal lock" method - ugly. I think, that the command/return code query should be as atomic as possible to prevent concurrent vmcp calls from disturbing each other. I think for application programmers this is quite simple, they can always use the device node, which guaqrantees to separate each call from others. The only open question is, how to solve our needs in scripts. I still like the stderr method, but will discuss this question with some colleagues if we can think of a better method. -- Mit freundlichen Grüßen / Best Regards / Un cordial saludo Christian Bornträger Linux Software Engineer zSeries Linux & Virtualization IBM Deutschland Entwicklung GmbH email: [EMAIL PROTECTED] Tel +49 7031 16 1975 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
