From owner-freebsd-hackers Wed May 21 10:33:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA22803 for hackers-outgoing; Wed, 21 May 1997 10:33:54 -0700 (PDT) Received: from gargoyle.bazzle.com (gargoyle.bazzle.com [206.103.246.190]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA22794 for ; Wed, 21 May 1997 10:33:49 -0700 (PDT) Received: from localhost (ejc@localhost) by gargoyle.bazzle.com (8.8.5/8.6.12) with SMTP id NAA06887; Wed, 21 May 1997 13:33:22 -0400 (EDT) Date: Wed, 21 May 1997 13:33:22 -0400 (EDT) From: "Eric J. Chet" To: "Russell L. Carter" cc: Amancio Hasty , Jake Hamby , hackers@FreeBSD.ORG Subject: Re: thread problem, RELENG_2_2: Re: omniORB port to FreeBSD In-Reply-To: <33831E47.5E89A044@consys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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 >