Ticket UUID: | 3382532 | |||
Title: | Synchronous geturl uses vwait | |||
Type: | Bug | Version: | None | |
Submitter: | ferrieux | Created on: | 2011-07-29 23:01:38 | |
Subsystem: | 29. http Package | Assigned To: | patthoyts | |
Priority: | 5 Medium | Severity: | Minor | |
Status: | Open | Last Modified: | 2022-09-10 12:07:04 | |
Resolution: | None | Closed By: | nobody | |
Closed on: | ||||
Description: |
This makes it impossible to use a synchronous geturl in an otherwise event-driven program (nested vwaits). | |||
User Comments: |
kjnash added on 2022-09-10 12:07:04:
The patch no longer works with current http. The http package now has more asynchronous code than it did when this bug was filed in 2011. http::Event has been made into a coroutine that yields to the event loop, with the connection made permanently non-blocking, in order to implement HTTP/1.1 pipelining. Part of http::geturl was given the same treatment in order to prevent blocking during socket connection. Many users want http::geturl to be asynchronous and to avoid long-running events that block a return to the event loop. These recent revisions are not needed for a synchronous HTTP connection. The simplest way to implement synchronous http::geturl would be to use an earlier version of http with the patch provided by ferrieux. However, the issues with -queryprogress, -querychannel, -channel, and -timeout would remain. An alternative might be to use a synchronous thread::send to run http::geturl asynchronously in another thread. However there will be issues about how much of the script would need to be accessible to the thread running geturl. The -proxyfilter, -progress and -queryprogress commands, the file sockets used by -channel and -querychannel, cookies, TLS and the certificate store, etc. I do not see an easy way to do synchronous http::geturl without the vwait nesting problem. ferrieux added on 2011-07-31 23:07:16: File Added - 419867: httpsync.patch ferrieux added on 2011-07-31 22:53:11: -querychannel and -channel also prevent the sync mode. The former for the same reason as -queryprogress (undocumented assumptions in tests); the latter because of heavily async fcopy machinery (could be relaxed). ferrieux added on 2011-07-31 22:44:00: File Deleted - 419862: ferrieux added on 2011-07-31 22:21:18: File Added - 419862: httpsync.patch ferrieux added on 2011-07-31 22:20:44: Attached, very small, patch restores the fully sync behavior when neither -nocommand nor -timeout nor -queryprogress are specified. (Note that the fact that -queryprogress makes geturl async is not documented, and is nonetheless enforced by the http::wait in test http-3.10. So the current patch is also working around another misbehavior) |
Attachments:
- httpsync.patch [download] added by ferrieux on 2011-07-31 23:07:16. [details]