Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 19 Apr 2011 12:50:25 +0300
From:      Andriy Gapon <avg@FreeBSD.org>
To:        Jung-uk Kim <jkim@FreeBSD.org>, freebsd-java@FreeBSD.org
Subject:   Re: firefox 4, openjdk6, icedtea - a problem
Message-ID:  <4DAD5AE1.9010302@FreeBSD.org>
In-Reply-To: <201103281727.50256.jkim@FreeBSD.org>
References:  <4D90F7BC.3050107@freebsd.org> <201103281727.50256.jkim@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help

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.
Not sure where things go wrong though.
Maybe something in glib, maybe firefox somehow messes up its polling.

Maybe this would ring a bell for anybody.
-- 
Andriy Gapon



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DAD5AE1.9010302>