bugGNU Octave - Bugs: bug #56828, urlread/urlwrite/webread functions...

 
 

bug #56828: urlread/urlwrite/webread functions are not interruptible with Ctrl+C

Submitter:  Mike Miller <mtmiller>
Submitted:  Fri 30 Aug 2019 12:52:06 AM UTC
   
 
Category:  Octave Function Severity:  2 - Minor
Priority:  5 - Normal Item Group:  Regression
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Tue 03 Sep 2019 04:54:26 PM UTC, comment #3: 

Thanks Kai. As I understand it, the intent of the change was to always handle signals in Octave, not in external code. So correspondingly, we need to ensure that calls into external code do not block for long periods of time. The way I read the comment, the goal is not to rework signal handling yet again, but to address each case individually and delete the obsolete macro as they are fixed.

Mike Miller <mtmiller>
Group Member
Sun 01 Sep 2019 04:55:10 PM UTC, comment #2: 

Confirmed too.  As you observed in comment #1, this problem seems to be related to the actual change of the macro "BEGIN_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE" to do effectively nothing at the moment.

https://hg.savannah.gnu.org/hgweb/octave/file/60bb69799591/liboctave/util/quit.h#l196
https://hg.savannah.gnu.org/hgweb/octave/file/60bb69799591/liboctave/util/url-transfer.cc#l376

I grepped for all occurrences of this macro, and it is indeed only used for urltransfer and some parse factorization functions.  Thus the damage is limited, but also visible for the sparse functions, which are also not stoppable, when inside the foreign code.


$ ./octave-4.2.2 --no-gui
GNU Octave, version 4.2.2
[...]
octave:1> [Q, R] = qr (sprand (10000, 10000, 1/10));
^C^CPress Control-C again to abort.

octave:1> exit

$ ./octave-4.4.1
GNU Octave, version 4.4.1
[...]
octave:1> [Q, R] = qr (sprand (10000, 10000, 1/10));
^C^C^C
^C
octave:1>


Each ^C represents an attempt to stop the function.  On the other hand, the following simplified C program can be stopped at any time by ctrl+c.


#include <curl/curl.h>

int main () {
  CURL *curl = curl_easy_init();
  if(curl) {
    CURLcode res;
    curl_easy_setopt(curl, CURLOPT_URL,
      "http://slowwly.robertomurray.co.uk/delay/10000/url/http://www.gnu.org/");
    res = curl_easy_perform(curl);
    curl_easy_cleanup(curl);
  }
  return 0;
}


Thus as you observed, Octave must be able to permit the external library to detect ctrl+c again.  I need to get familiar with how Octave handles it signals in this situation.

Kai Torben Ohlhus <siko1056>
Group Member
Fri 30 Aug 2019 04:51:15 PM UTC, comment #1: 

This is a regression from Octave 4.2 when the signal handling stack was refactored. The url_transfer::perform method is labeled as being interruptible in a foreign library, but it no longer is with the current signal handling approach.

Maybe there is a way to rewrite url_transfer::perform so that the request is performed non-blocking with a callback or some kind of sentinel that can be polled for completion in an interruptible loop?

Mike Miller <mtmiller>
Group Member
Fri 30 Aug 2019 12:52:06 AM UTC, original submission:  

If a server responds slowly to a HTTP request, the function can't be interrupted in Octave, and it hangs until the request times out or the server eventually responds. The only way to unblock it is to kill Octave with SIGKILL.

To simulate this, I used the "slowwly" web service to introduce a fixed delay. The call hangs and cannot be interrupted until the server responds. Examples with a 10 second delay:


url_real = "http://www.gnu.org/";
url = ["http://slowwly.robertomurray.co.uk/delay/10000/url/", url_real];
out = urlread (url);
## OR
out = webread (url);


Mike Miller <mtmiller>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by siko1056 (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-04-27 mtmiller Dependencies- bugs #58257 is dependent
    2019-08-30 mtmiller Severity1 - Wish 2 - Minor
        Item GroupFeature Request Regression
        StatusNone Confirmed
    2019-08-30 mtmiller Carbon-CopyRemoved 80942 -

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code