[Fwd: [omniORB] Timeout problems]

[Giga Giguashvili]

This is a multi-part message in MIME format.
--------------27710F87E5A51D1A8A7985FA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello,

timedwait is fine. It's just I stopped it in debugger and its' timeout passed...
Regarding the thread examples: I think there is something wrong with them.
I'll have to work on it for little more (comparing with the regular OMNI).

Thanks,
Giga.

Sai-Lai Lo wrote:

> Please check your implementation of omni_condition::timedwait().
> It is not returning from a time out as it should do.
> I'll suggest you verify your omni_thread port to sprocs by at least running
> the thread examples in src/examples/thread.
>
> Sai-Lai
>
> >>>>> Giga Giguashvili writes:
>
> > Hi,
>
> > I investigated the subject little more and found out that on of the threads(processes) gets
> > stuck with the stack frame I attach. I tried to debug eg2_clt example, while the server
> > implementation
> > was changed not to return from the hello function call for a long time.
>
> > I want to remind you that I ran the application with client call timout 1 sec.
> > Could someone explain me what is the mechanism for timeouts used in OMNI (I mean
> > where is the select call that sets the timeout??? :)))
>
> > Thank you again for your help,
> > Best regards,
> > Giga
>
> > -------- Original Message --------
>
>
> >       Subject:  [omniORB] Timeout problems
>
> >          Date:  Wed, 29 Mar 2000 16:53:56 +0200
>
> >          From:  Giga Giguashvili <gregoryg@ParadigmGeo.com>
>
> >  Organization:  Paradigm Geophysical Ltd.
>
> >            To:  omniorb-list@uk.research.att.com
>
>
> > Hello,
>
> > I have OMNI 2.8 ported for SGI platform which is using sprocs instead of pthreads.
> > I encountered some problems with timeouts on connections. After little debugging I
> > found out that shutdown function never gets called, even if I had set timeout through
> > the command line or function.
>
> > I wanted to ask where to start looking for the problem, which module to your opinion
> > might cause such a problem.
>
> > Thank you in advance,
> > Giga__poll(<stripped>) ["poll.s":20]
> > _poll(<stripped>) ["pollSCI.c":30]
> > omni_condition::timedwait(this = 0x10024ce4, secs = 954351369, nanosecs = 757573000) ["sproc.cc":247]
> > omniORB_Scavenger::run_undetached(this = 0x10024cb0, <no name> = 0x0) ["scavenger.cc":326]
> > omni_thread::_thread_func_wrapper(data = 0x10024cb0) ["sproc.cc":432]
> > _nsproc(<stripped>) ["sproc.s":226]
> > _poll(<stripped>) ["pollSCI.c":30]
> > __recv(<stripped>) ["recv.s":17]
> > _recv(<stripped>) ["recvSCI.c":29]
> > tcpSocketStrand::ll_recv(this = 0x100299f8, buf = 0x1002baa0, sz = 8200) ["tcpSocketMTfactory.cc":861]
> > reliableStreamStrand::fetch(this = 0x100299f8, max = 0) ["relStream.cc":252]
> > reliableStreamStrand::receive(this = 0x100299f8, size = 8192, exactly = '\000', align = 8, <no name> = '\001') ["relStream.cc":116]
> > NetBufferedStream::receive(this = 0x7fff2bec, minimum = 8, startMTU = '\001') ["nbufferedStream.cc":331]
> > NetBufferedStream::align_and_get_bytes(this = 0x7fff2bec, align = ALIGN_1__4omni, nbytes = 8, startMTU = '\001') ["bufferedStream.h":455]
> > NetBufferedStream::get_char_array(this = 0x7fff2bec, b = 0x7fff2ad0 = "", size = 8, align = ALIGN_1__4omni, startMTU = '\001') ["nbufferedStream.cc":154]
> > GIOP_C::ReceiveReply(this = 0x7fff2be8) ["giopClient.cc":205]
> > OmniProxyCallWrapper::invoke(o = 0x100252e0, call_desc = 0x7fff2d40) ["proxyCall.cc":99]
> > _proxy_Echo::echoString(<stripped>) ["echoSK.cc":74]
> > hello(obj = 0x10025314) ["greeting.cc":26]
> > main(argc = 2, argv = 0x7fff2e64) ["eg2_clt.cc":28]
> > __start(<stripped>) ["crt1text.s":177]
>
> --
> Sai-Lai Lo                                   S.Lo@uk.research.att.com
> AT&T Laboratories Cambridge           WWW:   http://www.uk.research.att.com
> 24a Trumpington Street                Tel:   +44 1223 343000
> Cambridge CB2 1QA                     Fax:   +44 1223 313542
> ENGLAND

--------------27710F87E5A51D1A8A7985FA
Content-Type: text/x-vcard; charset=us-ascii;
 name="gregoryg.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Giga Giguashvili
Content-Disposition: attachment;
 filename="gregoryg.vcf"

begin:vcard 
n:Giguashvili;Gregory
tel;fax:+972-9-970-9337
tel;work:+972-9-970-9379
x-mozilla-html:FALSE
org:Paradigm Geophysical
adr:;;Gav Iam 3 Shenkar St. 9;Hetzelia Pituakh;;46120;Israel
version:2.1
email;internet:gregoryg@paradigmgeo.com
title:Software Engineer
fn:Gregory Giguashvili
end:vcard

--------------27710F87E5A51D1A8A7985FA--