W3C home > Mailing lists > Public > www-lib@w3.org > July to September 2001

AW: How do I get out of an event loop?

From: Oliver Steinau <Oliver.Steinau@STencode.de>
Date: Tue, 21 Aug 2001 08:59:50 +0200
Message-ID: <2B88AE35C609DF4F852D31FFA6FD5EE601A392@CAESAR.STencode.de>
To: <jamesbrown@shopswell.com>
Cc: <www-lib@w3.org>
James,

taking about redirection... I also wanted to do the redirection myself
(and check for circular loops [aren't loops always circular?
Hmmm...;-)]) It worked fine as long as I had a per-request filter that
got called after the request was done -- I got a 301, checked the
response's redirection_anchor, and just continued with the event loop.
However, after I ran into various problems that you know of, I now have
no per-request filter at all, to the effect that I never get informed of
a redirection at all. I tried using HTAlert_add with HT_A_CONFIRM and
check for HT_MSG_REDIRECTION, but never got it. Same with HT_PROG_DONE;
this one is called only after the request has finished completely --
including redirection....
So, if you by any chance find out how one can intercept redirection, let
me know...

Thanks a lot,

/oliver

-----Ursprüngliche Nachricht-----
Von: James D. Brown [mailto:jamesbrown@shopswell.com]
Gesendet: Montag, 20. August 2001 19:12
An: Oliver Steinau; www-lib@w3.org
Betreff: How do I get out of an event loop?


After some recent code changes in my own code to add support for
redirection, 
I'm running into a similar access violation under MandrakeLinux 8.0.
After 
several hours of debugging, it appears that calling
HTEventList_stopLoop() 
may be a bad thing to do in some cases, which the docs DO warn about.

What appears to be happening is that I call HTEvent_stopLoop() while
some 
events are still pending (haven't had a chance to walk the event list
yet), 
and then go on to HTRequest_delete() the request.  At some later point,
it 
appears an Event still has hold of the original request pointer and
tries to 
access it in the next event loop.  Since the old request was deleted, we
get 
an access violation soon thereafter.

My apologies to Oliver for leading him astray on this issue, but I
didn't 
start having problems until adding redirection support in my app.

In any case, just like Oliver's, my event loop will not return without 
HTEvent_stopLoop().  In an attempt to fix this problem, I modified my
code to 
use the same HTRequest structure for all my requests.  This gets me
further 
in my processing, but then I run into an endless loop with the following

debugs:

HTTP Clean.. Called with status 302, net (nil)
Net Object.. Delete (nil) and call AFTER filters
Host Event.. READ passed to (URL DELETED) Terminated

I tried using HTNet_isIdle() before the call to HTEventList_stopLoop(),
but 
busy-waiting for an idle condition here means an endless loop (the event
list 
doesn't get processed, apparently), and checking once means I'm never
idle by 
the time I get there, so I get into an endless loop because I never call

HTEventList_stopLoop().

Clearly, we're running into a problem in that not all our filters are
being 
called with the HTEventList()_stopLoop(), but it's not clear to me how
to 
return from an event loop without the stopLoop call.

The examples I've looked at all call exit() in the terminate handler,
which 
of course doesn't help us any.

Since I started running into this problem with redirections, I'll try
pulling 
out the default redirect handler (I want to handle this myself, anyway),
and 
see where I get with that.

Two questions I'd like to add to Oliver's:

1) Is it possible to return from an event loop without
HTEvent_stopLoop()?  
If so, how?  If not, how do we deal with the pending events cleanly?

2) Is it reasonable to use the same HTRequest structure over and over?

Thanks!
James
_______________________________________________________
James D. Brown, President, Shopswell, Inc.
Voice: 303-400-0480 - FAX: 303-400-7181
http://www.shopswell.com - jamesbrown@shopswell.com
Received on Tuesday, 21 August 2001 03:00:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 23 April 2007 18:18:39 GMT