s900387@minyos.xx.rmit.oz.au (Craig Macbride) (05/13/91)
I have been doing some work with some code for clients which find servers
through the location broker and then access them via rpc calls. On Apollos
where there is concurrent programming support, all is well. On an hp9000
822, which is probably going to be the target machine (despite extremely
poor pre-sale response by HP), we had to code around the lack of concurrent
programming support. That was OK, but the server wakes up every second, even
when there is no activity from the client (or the server's other sources of
input) at all. Something from within the rpc calls seems to be sending an
alarm signal every second for no obvious reason.
This occurs even if the client process is on an Apollo (DN3500), and doesn't
occur if the server is run on an Apollo, even if the client is on the HP 9000.
To get around the lack of concurrent programming support on the HP 9000, we
are using a select() call. Even if we ignore SIGALRM, the select still gets
woken up every second.
By virtue of the way this software is being designed, and what it's for, we have
no real choice but to have client processes and server processes sitting around
quite possibly inactive in large numbers in the final production system, and
having every one of these processes wake up every second is totally
unacceptable. Do any of you know what is setting the alarm and associated
events and how to turn it off? Even when we are not relying on CPS, the Apollo
doesn't do it, so clearly it's not necessary to the implementation of what we
are doing.
I am posting this here as our local HP office who originally said they would
supply someone for the development team for this project then decided not to
(without telling anyone!) and have shown no desire to provide any help on this
question. Well, that's not quite true ... they suggested we contact an
independent contractor who'd know more about it than they would!
Any suggestions, including comments as to other platforms which have better
rpc ports than the hp9000, would be greatly appreciated.
--
_--_|\ Craig Macbride <uni: s900387@minyos.xx.rmit.oz.au>
/ \ <work: craig@bacchus.esa.oz.au>
\_.--.*/
vfkittred@bbn.com (Fletcher Kittredge) (05/15/91)
In article <1991May12.172642.6715@minyos.xx.rmit.oz.au> s900387@minyos.xx.rmit.oz.au (Craig Macbride) writes: >I have been doing some work with some code for clients which find servers >through the location broker and then access them via rpc calls. On Apollos >where there is concurrent programming support, all is well. On an hp9000 >822, which is probably going to be the target machine (despite extremely >poor pre-sale response by HP), we had to code around the lack of concurrent >programming support... > ... > ... > ... >Any suggestions, including comments as to other platforms which have better >rpc ports than the hp9000, would be greatly appreciated. Craig, you will be wanting OSF DCE or OSF/1 on HP or DEC systems. Both OSF/1 and OSF DCE include Pthreads (draft 4) support. What you need to do is find out *WHEN* HP is planning to release OSF/1, DCE or Pthreads support on your target platform. DEC has already released OSF/1... I suspect HP will not be far behind. regards, fletcher Fletcher Kittredge Senior Engineer, BBN Software Products 150 CambridgePark Dr, Cambridge, MA. 02140 617-873-3465 / fkittred@bbn.com / fkittred@das.harvard.edu