|
List Info
Thread: Block on oneways
|
|
| Block on oneways |
 
Denmark |
2007-09-26 03:11:34 |
Hi,
I've been thinking about this problem:
http://www.mai
l-archive.com/orbit-list gnome.org/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 <coldingomesc.com>
+
+ * 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.mai
l-archive.com/orbit-listgnome.org/msg00065.html
+
2007-09-25 Jules Colding <coldingomesc.com>
* test/timeout-server.c (main): Do not write more into
the
_______________________________________________
orbit-list mailing list
orbit-listgnome.org
htt
p://mail.gnome.org/mailman/listinfo/orbit-list
|
|
| Re: Block on oneways |
Denmark |
2007-09-26 03:28:00 |
On Wed, 2007-09-26 at 10:11 +0200, Jules Colding wrote:
> Hi,
>
> I've been thinking about this problem:
>
> http://www.mai
l-archive.com/orbit-listgnome.org/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 <coldingomesc.com>
+
+ * 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.mai
l-archive.com/orbit-listgnome.org/msg00065.html
+
2007-09-25 Jules Colding <coldingomesc.com>
* test/timeout-server.c (main): Do not write more
into the
_______________________________________________
orbit-list mailing list
orbit-listgnome.org
htt
p://mail.gnome.org/mailman/listinfo/orbit-list
|
|
| Re: Block on oneways |
 
United States |
2007-09-28 05:34:33 |
Hi Jules,
On Wed, 2007-09-26 at 10:11 +0200, Jules Colding wrote:
> http://www.mai
l-archive.com/orbit-listgnome.org/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.meeksnovell.com <><, Pseudo Engineer,
itinerant idiot
_______________________________________________
orbit-list mailing list
orbit-listgnome.org
htt
p://mail.gnome.org/mailman/listinfo/orbit-list
|
|
| Re: Block on oneways |
Denmark |
2007-09-28 05:34:53 |
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.mai
l-archive.com/orbit-listgnome.org/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-listgnome.org
htt
p://mail.gnome.org/mailman/listinfo/orbit-list
|
|
[1-4]
|
|