Date: Wed, 21 May 1997 13:33:22 -0400 (EDT) From: "Eric J. Chet" <ejc@bazzle.com> To: "Russell L. Carter" <rcarter@consys.com> Cc: Amancio Hasty <hasty@rah.star-gate.com>, Jake Hamby <jehamby@lightside.com>, hackers@FreeBSD.ORG Subject: Re: thread problem, RELENG_2_2: Re: omniORB port to FreeBSD Message-ID: <Pine.BSF.3.95q.970521131105.6827A-100000@gargoyle.bazzle.com> In-Reply-To: <33831E47.5E89A044@consys.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello I don't have a 2.2 box to try this out on. Try and give omniBroker a try it seems to be much less buggy than omniORB. It also supports more of the CORBA 2 spec than omniORB. You can find the port at ftp://ftp.freebsd.org/pub/FreeBSD/incoming/omniBroker_1.0R.tgz or ftp://ftp.bazzle.com/pub/corba/omniBroker_1.0R.tgz. Over 100BaseTX I'm seeing a member function call takes 1.33 milliseconds on average. Network traffic is 84 bytes for the call and 54 bytes for the return on average. This is for a simple member function without args. The -client box is a pentium 133, the server box is a AMD 486/133. Keep in mind g++ 2.7.2 with exceptions doesn't support the optimizer, performance should be even better with g++ 2.8 whenever it's released. These numbers are for omniBroker. Thanks, Eric Chet -- ejc@bazzle.com On Wed, 21 May 1997, Russell L. Carter wrote: > Seems Amancio and Eric got omniORB working on 3.0, but I havea problem > on RELENG_2_2. I needed to add > uthread_attr_create.c and uthread_attr_destroy.c to > lib/libc_r/uthread/Makefile.inc > and change an underscore in lib/libc/stdtime/localtime.c, > (pthread_key_create()), > now everything builds fine (with scads of warnings, but none look > relevant). > > but running omniNames hangs hard on exit, > here is the output from gdb: > > (gdb) run > Starting program: /u1/local/pkg/net/corba/omniORB_2.2.0/bin/omniNames > -start 22222 > > Tue May 20 17:11:07 1997: > > Starting omniNames for the first time. > Wrote initial log file. > Read log file successfully. > Root context is > IOR:010000002000000049444c3a436f734e616d696e672f4e616d696e67436f6e746578743a312e3000010000000000000024000000010100000900000031302e302e322e350000ce560c00000033823d9b995ab31600000001 > > Checkpointing Phase 1: Prepare. > Checkpointing Phase 2: Commit. > Checkpointing completed. // at this point hangs > ^C > Program received signal SIGINT, Interrupt. > 0x812d471 in _thread_sys_select () > (gdb) where > #0 0x812d471 in _thread_sys_select () > #1 0x81025dc in _thread_kern_sched_state () > #2 0x8101c9f in _thread_kern_sched () > #3 0x8102158 in _thread_kern_sched_state () > #4 0x80f5aea in accept () > #5 0x6f26e in tcpSocketRendezvous::accept (this=0xbc280) > at tcpSocket_UNIX.cc:737 > #6 0x626f5 in tcpsock_rendezvouser::run (this=0xbd1c0, arg=0x0) at > orb.cc:516 > #7 0x90930 in omni_thread::wrapper (ptr=0xbd1c0) at posix.cc:475 > #8 0x8102f01 in _thread_start () > (gdb) > > Any clues? I would prefer to get this going under RELENG_2_2, as the > system I have available (at work) keeps a slew of NT boxes under > control... If not, is it possible to push my way to 3.0 without a > complete reinstall? (2.1->2.2 went fine with some coaxing) > > Thanks, > Russell >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95q.970521131105.6827A-100000>