[PATCH] Block on oneways
|
View:
New views
4 Messages
—
Rating Filter:
Alert me
|
 |
[PATCH] Block on oneways
by colding
::
Rate this Message:
Hi,
I've been thinking about this problem: http://www.mail-archive.com/orbit-list@.../msg00065.html An easy, simple and foolproof way to fix this would be to make all oneways block while sending data(*). Another fix would be to put a ref on the connection if the send is a oneway, but that fix will be more involved and not as straightforward. Please comment. Thanks, jules (*) It doesn't look like link_connection_writev() even looks at the link options before eventually returning LINK_IO_QUEUED_DATA at line 1180... Index: src/orb/GIOP/giop-send-buffer.c =================================================================== --- src/orb/GIOP/giop-send-buffer.c (revision 2025) +++ src/orb/GIOP/giop-send-buffer.c (working copy) @@ -445,11 +445,15 @@ gboolean blocking) { int retval; + gboolean oneway; LinkConnection *lcnx = LINK_CONNECTION (cnx); - static LinkWriteOpts *non_block = NULL; + static LinkWriteOpts opts; - if (!non_block) - non_block = link_write_options_new (FALSE); + oneway = giop_send_buffer_is_oneway (buf); + if (oneway || blocking) + opts.block_on_write = TRUE; + else + opts.block_on_write = FALSE; /* FIXME: if a FRAGMENT, assert the 8 byte tail align, &&|| giop_send_buffer_align (buf, 8); */ @@ -457,16 +461,16 @@ if (g_thread_supported () && lcnx->timeout_msec && !lcnx->timeout_source_id - && !giop_send_buffer_is_oneway (buf)) { + && !oneway) { giop_timeout_add (cnx); } + retval = link_connection_writev (lcnx, buf->iovecs, buf->num_used, - blocking ? NULL : non_block); - - if (!blocking && retval == LINK_IO_QUEUED_DATA) + &opts); + if (!opts.block_on_write && (retval == LINK_IO_QUEUED_DATA)) retval = 0; /* FIXME: we need to flag the connection disconnected on fatal error */ Index: ChangeLog =================================================================== --- ChangeLog (revision 2029) +++ ChangeLog (working copy) @@ -1,3 +1,10 @@ +2007-09-26 Jules Colding <colding@...> + + * src/orb/GIOP/giop-send-buffer.c (giop_send_buffer_write): + Make oneway conenctions block until all data has been send. Will + fix this: + http://www.mail-archive.com/orbit-list@.../msg00065.html + 2007-09-25 Jules Colding <colding@...> * test/timeout-server.c (main): Do not write more into the _______________________________________________ orbit-list mailing list orbit-list@... http://mail.gnome.org/mailman/listinfo/orbit-list |
|
|
Re: [PATCH] Block on oneways
by colding
::
Rate this Message:
On Wed, 2007-09-26 at 10:11 +0200, Jules Colding wrote:
> Hi, > > I've been thinking about this problem: > > http://www.mail-archive.com/orbit-list@.../msg00065.html > > An easy, simple and foolproof way to fix this would be to make all > oneways block while sending data(*). Another fix would be to put a ref > on the connection if the send is a oneway, but that fix will be more > involved and not as straightforward. > > Please comment. Corrected patch below. This one actually compiles... -- jules Index: src/orb/GIOP/giop-send-buffer.c =================================================================== --- src/orb/GIOP/giop-send-buffer.c (revision 2025) +++ src/orb/GIOP/giop-send-buffer.c (working copy) @@ -445,11 +445,13 @@ gboolean blocking) { int retval; + gboolean oneway; LinkConnection *lcnx = LINK_CONNECTION (cnx); - static LinkWriteOpts *non_block = NULL; + static LinkWriteOpts *opts = NULL; - if (!non_block) - non_block = link_write_options_new (FALSE); + oneway = giop_send_buffer_is_oneway (buf); + if (oneway || blocking) + opts = link_write_options_new (TRUE); /* FIXME: if a FRAGMENT, assert the 8 byte tail align, &&|| giop_send_buffer_align (buf, 8); */ @@ -457,18 +459,22 @@ if (g_thread_supported () && lcnx->timeout_msec && !lcnx->timeout_source_id - && !giop_send_buffer_is_oneway (buf)) { + && !oneway) { giop_timeout_add (cnx); } + retval = link_connection_writev (lcnx, buf->iovecs, buf->num_used, - blocking ? NULL : non_block); - - if (!blocking && retval == LINK_IO_QUEUED_DATA) + opts); + if (!(oneway || blocking) && (retval == LINK_IO_QUEUED_DATA)) retval = 0; + if (opts) { + g_free (opts); + opts = NULL; + } /* FIXME: we need to flag the connection disconnected on fatal error */ return retval; Index: ChangeLog =================================================================== --- ChangeLog (revision 2029) +++ ChangeLog (working copy) @@ -1,3 +1,10 @@ +2007-09-26 Jules Colding <colding@...> + + * src/orb/GIOP/giop-send-buffer.c (giop_send_buffer_write): + Make oneway conenctions block until all data has been send. Will + fix this: + http://www.mail-archive.com/orbit-list@.../msg00065.html + 2007-09-25 Jules Colding <colding@...> * test/timeout-server.c (main): Do not write more into the _______________________________________________ orbit-list mailing list orbit-list@... http://mail.gnome.org/mailman/listinfo/orbit-list |
|
|
Re: [PATCH] Block on oneways
by michael meeks
::
Rate this Message:
Hi Jules,
On Wed, 2007-09-26 at 10:11 +0200, Jules Colding wrote: > http://www.mail-archive.com/orbit-list@.../msg00065.html Hmm :-) >An easy, simple and foolproof way to fix this would be to make all > oneways block while sending data(*). Which would (unfortunately) nullify one of the major advantages of oneways (asynchronicity) - the other end may not be interested in reading. > Another fix would be to put a ref on the connection if the send is > a oneway, but that fix will be more involved and not as straightforward. Hmm; it's clear that when a connection is finally unreffed we need to do better wrt. sending all the queued data. This I guess ties into the problems with shutdown and flushing data then. What do we do with incoming calls on connections we are unreffing ? Anyhow - the simplest approach I would have thought would be to keep a ref on the connection while there is queued data, or at least some form of weak-ref (right?). HTH, Michael. -- michael.meeks@... <><, Pseudo Engineer, itinerant idiot _______________________________________________ orbit-list mailing list orbit-list@... http://mail.gnome.org/mailman/listinfo/orbit-list |
|
|
Re: [PATCH] Block on oneways
by colding
::
Rate this Message:
Hi Michael,
On Fri, 2007-09-28 at 11:34 +0100, Michael Meeks wrote: > Hi Jules, > > On Wed, 2007-09-26 at 10:11 +0200, Jules Colding wrote: > > http://www.mail-archive.com/orbit-list@.../msg00065.html > > Hmm :-) > > >An easy, simple and foolproof way to fix this would be to make all > > oneways block while sending data(*). > > Which would (unfortunately) nullify one of the major advantages of > oneways (asynchronicity) - the other end may not be interested in > reading. Yes, agreed. > > Another fix would be to put a ref on the connection if the send is > > a oneway, but that fix will be more involved and not as straightforward. > > Hmm; it's clear that when a connection is finally unreffed we need to > do better wrt. sending all the queued data. This I guess ties into the > problems with shutdown and flushing data then. Absolute. This is the core of the old problem you and I wrote about back then. The connection shouldn't die until all queued data has been sent. > What do we do with > incoming calls on connections we are unreffing ? Drop them on the floor I guess? > Anyhow - the simplest approach I would have thought would be to keep a > ref on the connection while there is queued data, or at least some form > of weak-ref (right?). Well, I mainly did the patch as a way to fix it really quickly and in the hope that others would chime in with a more effective approach. So yes, you are probably right. Best regards, jules _______________________________________________ orbit-list mailing list orbit-list@... http://mail.gnome.org/mailman/listinfo/orbit-list |
| Free embeddable forum powered by Nabble | Forum Help |
