Re: ORBit-0.5.7 bug: non-root process can't talk to root process!

[Yonghong Chen <yonghong nayna com>]

Thank you, Sebastian,

> See Question 2b) on
> 
>    http://orbit-resource.sourceforge.net/faq.html#orbit
> 
Thanks again and I will try to resolve my problem according this way.

> 
> >   res = writev(fd, curvec, nvecs);
> >
> >   sum = (GIOP_MESSAGE_BUFFER(send_buffer)->message_header.message_size +
> > sizeof(GIOPMessageHeader));
> >
> >   if(res < sum) {
> >     if(res < 0) {
> >       if(errno != EAGAIN) {
> >         giop_main_handle_connection_exception(cnx);
> >         goto out;
> >       }
> >
> >       res = 0;
> 
> This is from the original code. This should actually do, what you want, or am
> I missing something? In giop_init SIGPIPE is set to ignore, which means, that
> write will set errno to EPIPE, which is != EAGAIN and thus the connection is
> marked invalid.
> 

Yes, this is from the original code, but it really doesn't do what I
want.

You can download the echo example on
ftp://opera.u-strasbg.fr/pub/ORBit/orbit-docs.tar.gz
and test it as follows:
(1) run echo-server, run echo-client, kill echo-server, and now you can
see what happens on echo-client

(2) run echo-server, run echo-client on gdb, kill echo-server, and now
you can see what happens on echo-client, now you will know SIGPIPE is
not ignored (you are right, giop_init ignores SIGPIPE, but it doesn't
work there.  I don't know why).

(3) if you ignore SIGPIPE before writev, it is true  
giop_main_handle_connection_exception() will be called.  However, the
echo-client still hangs without any error message.  The reason is
giop_main_handle_connection_exception() do too much staff more than we,
or I, need, and then, CORBA_Enviorment ev._major will be set
CORBA_NO_EXCEPTION, that is the reason that echo-client still hangs. 
Actually, if we don't call giop_main_handle_connection_exception() when
SIGPIPE happens, echo-client will die as we expect.

(4) In my modified version, I copy the whole codes from
giop_main_handle_connection_exception() and put into if(errno==EPIPE)
block as follows:


    if(errno == EPIPE) {
/*
giop_main_handle_connection_exception(cnx);
*/
        /* Sounds like
giop_main_handle_connection_exception do too
much,
         * if it is directly called,
CORBA_Enviorment ev's _major will
         * be set as CORBA_NO_EXCEPTION
*/

      /* The following statements are just a
copy    of the original
       * giop_main_handle_connection_exception
but I comment some out
       */
      giop_connection_ref(cnx);
 
/*     
giop_connection_remove_from_list(cnx);
*/
        /* Sounds like if this connection cnx
is removed from the global
         * giop_connection_list,
CORBA_Enviorment ev's _major will be
         * set as CORBA_NO_EXCEPTION.  Then I
have to comment it out.
         */
 
      shutdown(fd, 2);
//      close(fd);
//      GIOP_CONNECTION(cnx)->fd = -1;
//      cnx->is_valid = FALSE;
        /* UNIX docments say after close a fd
by close(), the fd
         * couldn't be used any more in that
process.
         * Since this connection has not been
removed from the global
         * list, this fd has been used later
at somewhere.
         * Actually, using close(), I get some
warning message.
         * On the other hand, shutdown()
already closes this connection.
         */

      if(cnx->incoming_msg) {
        giop_recv_buffer_unuse(cnx->incoming_msg);
        cnx->incoming_msg = NULL;
     
}

      giop_connection_unref(cnx);
      /* End of
giop_main_handle_connection_exception. */
 
      goto out;
    }

(5) Finally, you can test echo example with my modified code, you will
see echo-client will gracefully die after the echo-server is turned off.

(6) Should we initialize "res" as -1?  Since the first value assigned to
"res" is the return value of writev(), but that statement could be
failed.

Hope I make myself clear this time.

Thanks,
Yonghong