RE: Handling Errors and Interruptions

Hi Michael,

did you look at http://www.w3.org/Library/Examples/eventloop.c ?
There also were some emails with questions somewhat close to yours in December -
February (you can find it in mailing list archives).

Olga.

On 13-May-99 Michael Saunders wrote:
> Hi,
> 
> Based on libwww example applications, 'LoadToFile.c' and 'put.c', I have
> created
> utility to transfer a document from a local file system to a URL and visa
> versa.
> I have been using non-preemptive pseudo threads (non-blocking sockets) and a
> no
> cache client profile.
> 
> I am encountering three problems that may be related:
> 
>       1) While a request is in the process of downloading or uploading
>          a file how does one stop the transfer? I have attempted all
>          variations of trying to kill the request from the progress
>          alert dialog and from a timer with no effect, the transfer
>          just keeps on going. How do you cleanly stop a request that
>          is in progress?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
?? I do not know... Except if you have separate client  then it can
kill the server (in bad hang cases for example) and restart it afresh. 

> 
>       2) This utility I created is only a test for a larger project.
>          What I want to do is have my main application's X event loop
>          separate from the libwww event loop (mostly because I don't
>          understand how to integrate to two yet). Therefore after a
>          download request completion I want to exit the loop and
>          return to my main application's X event loop. To do this I
>          put a "if (HTNet_isIdle()) HTEventList_stopLoop();" construct
>          in the HT_PROG_DONE section of the progress alert dialog.
>          This works fine for a successful download but not for a
>          failed one (lets say a bad host name is specified). I tried
>          putting the same construct after the printing the "bad host
>          error message" but it indicates that it is not idle, i.e.
>          requests are still pending.
> 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I have implemented a separate libwww server and my application talks to it
throuhg the socket whenever it needs some network download or upload.
For the requests I am setting the callback terminate handler (After filter)
which after cleaning the request sends results to the client application
through the socket and then listens to the next request from client. When new
request arrives termination handler issues new request and returns (and so
on...). There are some problems with this approach though.


>       3) Certain poorly formed URLs will cause the select() to block.
>          Even the 'LoadToFile' application will hang on the select()
>          call (because the last argument to select(), a pointer to
>          timeval, is mysteriously NULL for certain cases of a poorly
>          formed URLs). You can duplicate the problem by giving the
>          LoadToFile example a URL to a known ftp server but to a
>          file that does not exist. How do you break out of these
>          errors? You can also cause 'LoadToFile' to hang if
>          you enter a bad target file by incorrectly specifying
>          a "file:" prefix:
>               LoadToFile ftp://myHost/myFile.txt -o file:/tmp/myFile.txt
> 

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I had the same problem for which I checked if last argument is NULL. For such
cases I got a new NULL-valued timeval structure and passed it as the last
argument instead of just NULL. That seemed to cure the problem. 

> Can anyone get me pointed in the correct direction? I have been pulling my
> hair
> out try to solve the problems. I like the architecture of the library and
> would
> like to use it but I have to solve these problems to make it acceptable for
> the
> end user.
> 
> Thanks,
> Michael

----------------------------------
E-Mail: olga <olga@eai.com>
Date: 13-May-99
Time: 10:18:17

This message was sent by XFMail
----------------------------------

Received on Thursday, 13 May 1999 11:42:20 UTC