On Mon, May 30, 2011 at 12:32 PM, Jorge Arellano Cid <jcid@dillo.org> wrote:
Well after 2 days of chasing the non-connection bug, I'm still not successful in locating the bug. But first a few points:
1. Mac-Fltk 1.3 indeed contains code for "select"ing socket events. I found this myself and later Manolo verified it. The comment that Jorge mentioned is a leftover, but the code is there. In fact it runs in a pthread, and
On Mon, May 30, 2011 at 05:40:53AM -0500, reza farivar wrote: the
whole system wouldn't work without it anyway.
What did Manolo answer exactly?
Here's what I asked and his answer: "
Hi Manolo,
I'm working with "Dillo browser" people to get their browser, which uses FLTK 1.3, to compile and run on Mac OS X.
We have come across a bug in which the browser waits forever in a busy loop waiting for something from a connecting socket, which seems to come from FLTK.
Specifically, during the busy wait period it seems the program is stuck in fl_mac_flush_and_wait() from FL_cocoa.mm.
fl_mac_flush_and_wait in turn calls fl_wait(). I noticed that you have left a comment on top of fl_wait() mentioning:
\todo there is no socket handling in this code whatsoever
I also checked the fl_wait function for the unix versions in FL_x.cxx, and in there the function issues the "select" system call, while in the mac function it seems it's just a timeout loop?
Can you please verify if this is indeed a missing functionality waiting to be fixed? Is there a quick fix?
Hi Reza, I have no idea why this comment is there. It was in the Carbon version, and I didn't remove it. I know that Fl::add_fd() on a pseudoterminal works correctly (I use that in my app). I have checked with the button demo program (after changing #if 0 into #if 1) that Fl::add_fd() also works on stdin. Thus, my idea is that there was no missing functionality. But I may be wrong, and you may have discovered a bug. You would then have to file an STR in FLTK for that, and describe the problem as accurately as possible. Best wishes, Manolo ============================================================== Hi Reza, Below is the logical flow that handles file descriptors declared to FLTK with Fl::add_fd(). It is identical in essence to what it was during the Carbon era. The only change is that events are created, queued, and fetched the Cocoa way. in main thread: fl_mac_flush_and_wait fl_wait do_queued_events //start a thread devoted to fd handling: if ( dataready.GetNfds() ) dataready.StartThread(); //continue below in fd-handling thread: This thread runs DataReady::DataReadyThread() that does select() on current fd's. When data is ready, DataReadyThread() creates an application-defined event of subtype FLTKDataReadyEvent, puts it in the event queue, and the thread finishes. in main thread (continued): //the next event is fetched from the event queue: NSEvent *event = [NSApp nextEventMatchingMask:NSAnyEventMask ... //and the sendEvent function is called: [FLApplication sendEvent:event]; //in: (void)sendEvent:(NSEvent *)theEvent if the event type is NSApplicationDefined and the subtype is FLTKDataReadyEvent, call processFLTKEvent() call DataReady::HandleData() call the fd callback to process this data. Hoping this helps. Manolo =================================================================== Hi Reza, The threads demo program runs well on Mac OS. This shows that Fl::add_fd() is also correct for a pipe, as used in this program. I never tested a socket, though. "
2. So I'm now convinced the problem is somewhere in Dillo.
What did convince you?
The demo programs of FLTK work fine, and FLTK does issue a "select" system call in a thread. See in FLTK: src/Fl_cocoa.c, lines 364 to 409, and Manolo's comments above. On the other hand it seems the bug has to do with the contents of the pages being loaded. If the contents are such that it doesn't create conditions for a repush, things get stuck. Otherwise If the contents do force a repush in dillo, the other previous tabs start to load their contents. Finally as I mentioned earlier it seems the busy loop is an orthogonal issue, which always happens for the first tab, no matter what the contents are. It is probably a red herring, which sent us to the path of looking at fl_mac_flush_and_wait. But as soon as I open a second tab and enter a URL the busy wait stops and never happens again. But since the non-connection issue remains for the rest of the tabs, it makes me believe the non-connection bug is a separate issue to the busy wait of first tab, and has to do with conditions of a repush.
-- Cheers Jorge.-
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev