From owner-freebsd-java@FreeBSD.ORG Tue Apr 19 09:50:29 2011 Return-Path: Delivered-To: freebsd-java@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A64A7106564A; Tue, 19 Apr 2011 09:50:29 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B89748FC1A; Tue, 19 Apr 2011 09:50:28 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA26737; Tue, 19 Apr 2011 12:50:27 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QC7Zj-0008rA-0s; Tue, 19 Apr 2011 12:50:27 +0300 Message-ID: <4DAD5AE1.9010302@FreeBSD.org> Date: Tue, 19 Apr 2011 12:50:25 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110308 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Jung-uk Kim , freebsd-java@FreeBSD.org References: <4D90F7BC.3050107@freebsd.org> <201103281727.50256.jkim@FreeBSD.org> In-Reply-To: <201103281727.50256.jkim@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: firefox 4, openjdk6, icedtea - a problem X-BeenThere: freebsd-java@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting Java to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 09:50:29 -0000 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