Date: Tue, 19 Apr 2011 16:49:19 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: freebsd-java@FreeBSD.org Cc: gecko@FreeBSD.org, Jung-uk Kim <jkim@FreeBSD.org> Subject: Re: firefox 4, openjdk6, icedtea - a problem Message-ID: <4DAD92DF.3040303@FreeBSD.org> In-Reply-To: <4DAD5AE1.9010302@FreeBSD.org> References: <4D90F7BC.3050107@freebsd.org> <201103281727.50256.jkim@FreeBSD.org> <4DAD5AE1.9010302@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
on 19/04/2011 12:50 Andriy Gapon said the following:
>
> Here's a new twist.
> First, some more details. The applet in question would start normally, but then
> at some point it would seem to just hang. Then I accidentally noticed that if I
> let the applet to just sit there, then it would recover after some long-ish
> timeout, like 3 or 5 minutes.
>
> I started investigating that and here are some results.
> It seems that the plugin and a Java process that actually runs an applet
> communicate with each other over a couple of named pipes (fifos). I see the
> following when the hang happens:
> - the plugin sends GetJavaObject message to the applet runner via fifo #1
> - the applet runner gets the message, processes it and sends a reply via fifo #2
> - the plugin doesn't see the message and keeps waiting
> - the plugin finally times out and goes on to do other things
> - a while later the plugin reads the message from fifo #2
>
> So the problem seems to be that the plugin somehow doesn't see that there is a
> message available for it in the fifo (or doesn't even check) until much later.
>
> Some code snippets from the plugin code.
> That's how the reception channel is set up:
> in_from_appletviewer = g_io_channel_new_file (in_pipe_name,"r", &channel_error);
> in_watch_source =
> g_io_add_watch (in_from_appletviewer,
> (GIOCondition) (G_IO_IN | G_IO_ERR | G_IO_HUP),
> plugin_in_pipe_callback, (gpointer) in_from_appletviewer);
>
> That's how the plugin waits for a response:
> do
> {
> clock_gettime(CLOCK_REALTIME, &curr_t);
>
> if (!result_ready && (curr_t.tv_sec < t.tv_sec))
> {
> if (g_main_context_pending(NULL))
> g_main_context_iteration(NULL, false);
> else
> usleep(200);
> }
> else
> break;
>
> } while (1);
>
> I suppose that internally the glib code should perform some kind of poll/select
> on a fifo fd.
It seems that when the glib calls plugin_in_pipe_callback the associated fd is
removed from glib's "poll list" and depending on what the callback returns the fd
may be added back to the list.
In my case the IcedTea code makes another request to its java process while being
in plugin_in_pipe_callback and thus it "waits" for a response without the fifo fs
actually being polled.
I see that the triggering response from Java is "instance 2 url ..." and the
"nested" request from the plugin is "instance 2 reference -2 GetJavaObject".
It looks like while processing the first message the plugin calls into the browser
via browser_functions.geturl and the browser calls back into the plugin via
ITNP_GetValue(NPPVpluginScriptableNPObject).
Not sure if it's an IcedTea's fault then (mis-use of glib API), or if it's a fault
of Firefox 4.
Because the same plugin works OK with Firefox 3 and Chromium.
--
Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DAD92DF.3040303>