Re: libwww with glib/gtk+

On Fri, 22 Oct 1999 jose.kahan@w3.org wrote:

> Hello James,
> 
> In our previous episode, James Henstridge said:
> > 
> > A while back I posted about using libwww with gtk+.  I have the HTEvent
> > and HTTimer interfaces implemented correctly now, and was looking at
> > implementing some of the alert dialogs.
> 
> This is great. I had taken your previous implementation and interfaced it
> in our Amaya/gtk version. It worked quite well (except for the lack of
> timers).

Well this one now has timers if you want to use it.  The
glibwww-callbacks.c file is the one you would be looking for.

> 
> > Since I am implementing them in gtk, the event loop runs while the dialog
> > is on screen waiting for the user's input.  This also means that libwww
> > events and timers can be processed while the dialog is on screen (ie.
> > event and timer handlers will be called before the alert callback
> > function has returned). When this happens however, I get a segfault in
> > libwww.
> > 
> > Should I expect libwww to handle this condition, or do I have to write 
> > some code to suspend the HTEvents and HTTimers while the dialog is on
> > screen?
> 
> Let's say that libwww handles the network events and related timers your
> application may have set up. But it's the gtk (or is it gdk?) event loop 
> that connects events with the registred callbacks.
> 
> I don't think you should suspend your timers, as it'd mean something like
> "don't receive anything, not even timeouts, until the user pushes the
> done button".
> 
> I don't know which kind of event you're dealing in the dialogue message,
> but it may be there that you should suspend or kill the request, then
> launch it again.
> 
> I hope this helps you.
> 
> Thanks for your report!
> 
> -Jose
> 

I will try to give a better description of my problem ...

I was mainly having trouble with the IO events.  Here is a backtrace of a
port of the load to file example (it uses the glib mainloop and has some
gtk dialogs implementing the HTAlert stuff):

#0  0x4002e623 in HTMIME_put_block ()
#1  0x400229c3 in HTTPStatus_put_block ()
#2  0x40067b4e in HTReader_read ()
#3  0x4007dab8 in HTHost_read ()
#4  0x400234e6 in HTTPEvent ()
#5  0x4007b6ba in HostEvent ()
#6  0x804c770 in glibwww_io_func (source=0x80a2718, condition=G_IO_IN, 
    data=0x80a26d8) at glibwww-callbacks.c:157
#7  0x403ef5ee in g_io_unix_dispatch (source_data=0x80a3d28, 
    current_time=0xbffff38c, user_data=0x80a26d8) at giounix.c:135
#8  0x403f0b4f in g_main_dispatch (current_time=0xbffff38c) at gmain.c:656
#9  0x403f1137 in g_main_iterate (block=1, dispatch=1) at gmain.c:874
#10 0x403f12b9 in g_main_run (loop=0x80ab1a0) at gmain.c:932
#11 0x4023193b in gtk_main () at gtkmain.c:476
#12 0x400e7fba in gnome_dialog_run_real (dialog=0x80a4568, close_after=1)
    at gnome-dialog.c:660
#13 0x400e80ba in gnome_dialog_run_and_close (dialog=0x80a4568)
    at gnome-dialog.c:727
#14 0x804d782 in glibwww_prompt (request=0x8081360, op=HT_A_PROMPT,
msgnum=4, 
    dfault=0x80a4338 "/tmp/announce.php3?id=897987575", input=0x0, 
    reply=0x80a4328) at gnome-dialogs.c:288
#15 0x4006113b in HTSaveLocally ()
#16 0x4002de38 in pumpData ()
#17 0x4002e363 in HTMIME_put_block ()
#18 0x400229c3 in HTTPStatus_put_block ()
#19 0x40067b4e in HTReader_read ()
#20 0x4007dab8 in HTHost_read ()
#21 0x400234e6 in HTTPEvent ()
#22 0x4007b6ba in HostEvent ()
#23 0x804c770 in glibwww_io_func (source=0x80a2718, condition=G_IO_IN, 
    data=0x80a26d8) at glibwww-callbacks.c:157
#24 0x403ef5ee in g_io_unix_dispatch (source_data=0x80a3d28, 
    current_time=0xbffff798, user_data=0x80a26d8) at giounix.c:135
#25 0x403f0b4f in g_main_dispatch (current_time=0xbffff798) at gmain.c:656
#26 0x403f1137 in g_main_iterate (block=1, dispatch=1) at gmain.c:874
#27 0x403f12b9 in g_main_run (loop=0x80a2760) at gmain.c:932
#28 0x4023193b in gtk_main () at gtkmain.c:476
#29 0x804bca8 in main (argc=2, argv=0xbffff814) at testglibwww.c:50

at frame #23, an IO event gets handled.  In response, the HTSaveLocally
function calls an alert callback to get the name of the file to save.  The
gtk implementation of this function brings up a dialog with an entry in
it, and starts an other instance of the mainloop waiting for input (this
second main loop would return when the dialog is closed).  While waiting
for input, another IO event is handled, and causes a crash.  This would
not occur if the glib IO event handlers for libwww were destroyed when
the alert callback starts, and recreated when it finishes.

Does this sound like the correct aproach?

James.

--
Email: james@daa.com.au
WWW:   http://www.daa.com.au/~james/

Received on Saturday, 23 October 1999 21:26:31 UTC