Menu
▾
▴
[Tcl-bugs] [ tcl-Bugs-2911139 ] http::geturl abuses vwait on async call
|
From: SourceForge.net <no...@so...> - 2012-05-26 20:03:34
|
Bugs item #2911139, was opened at 2009-12-08 18:33 Message generated for change (Comment added) made by dkf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2911139&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 29. http Package >Group: current: 8.5.11 Status: Open Resolution: None Priority: 9 Private: No Submitted By: Alaoui Youness (kakaroto) Assigned to: Pat Thoyts (patthoyts) Summary: http::geturl abuses vwait on async call Initial Comment: Hi, As discussed on IRC with some of you, aMSN keeps crashing because of "too many nested evaluations", and it seems to be caused by a nested event loop by calling update/vwait/tkwait. I found out what the cause is and it seems to be coming from the http package. I'll just copy/paste what I said on IRC, and I'll attach a test tcl file to reproduce the problem : ========================================================== <KaKaRoTo> it basically simulates someone who tries to do 100 geturls asynchronously, and they're all being done from a timer where the geturl gets called after a simple execution stack of maybe 5 functions... <KaKaRoTo> with msn I have to do a SOAP (http) request for every contact, so if you have 200 contacts, I'd do 200 geturls.. <KaKaRoTo> I definitely want the geturl to be async! that's why I do -timeout to the geturl, but doing so makes http do a vwait, which causes the above error <KaKaRoTo> (ps launch the script with 'wish tst.tcl', if you just do tclsh, it will end because there's no mainloop) [...] <ijchain> <kbk> KaKaRoTo - Don't Do That. Use the -command option to http::geturl so that it doesn't block <KaKaRoTo> kbk: I use -command AND -timeout <KaKaRoTo> if -timeout is not specified then http will not create the socket with -async <KaKaRoTo> I was expecting my -command to get called if a connection error happens, or if the timeout was reached and the http request was not completed <KaKaRoTo> I don't understand why -timeout would make it async AND make it vwait... <ijchain> <kbk> Looking at the code -- <ijchain> <kbk> the only 'vwait' is in 'http_wait': <ijchain> <kbk> and the only call to http_wait is gated: <ijchain> <kbk> if {! [info exists state(-command)]} { <ijchain> <kbk> http_wait $token <ijchain> <kbk> } <KaKaRoTo> kbk: there's another one <KaKaRoTo> there are two calls to 'wait' in the geturl function <KaKaRoTo> # Wait for the connection to complete <KaKaRoTo> if {$state(-timeout) > 0} { <KaKaRoTo> fileevent $s writable [list http::Connect $token] <KaKaRoTo> http::wait $token <ijchain> <kbk> ugh - I'm looking at the wrong http.tcl, sec... <KaKaRoTo> kbk: np <KaKaRoTo> we use http 2.4.4, because we had problems with earlier versions, so people upgrade their system, amsn stops working etc.. so we bundle 2.4.4 and do a package require -exact 2.4.4 <KaKaRoTo> but I checked the version in CVS and it has the same code <ijchain> <kbk> KaKaRoTo - Log a bug. This can't be right. ========================================================== So, as explained, in my opinion, the http::geturl should use -async on the socket if -command is specified, it should also call the callback command in case of a connection error instead of vwait-ing in geturl to return an error. I hope this gets fixed soon... aMSN is basically completely broken for everyone because of this. Thanks, KaKaRoTo ---------------------------------------------------------------------- >Comment By: Donal K. Fellows (dkf) Date: 2012-05-26 13:03 Message: We should consider what impact coroutines would have on this in 8.6 ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2011-09-05 00:17 Message: Hum, looks like this got completely drowned, never committed to trunk, right ? As of today, in both 8.[56], there is no way to do a fully async http request (including an async connect): the code insists on doing [socket -async] *only* in presence of -timeout, and -timeout forces a vwait. Why that nonsense ? (Youness's version gets it right) ---------------------------------------------------------------------- Comment By: Alaoui Youness (kakaroto) Date: 2010-01-11 15:13 Message: typo in my previous comment, the url should have had revision=11889... anyways, I did a diff (ignoring whitespace changes) and I added it to this bug. Thanks for checking it out! ---------------------------------------------------------------------- Comment By: Alaoui Youness (kakaroto) Date: 2010-01-10 18:15 Message: Alright, I found the bug and fixed it in SVN revision 11889 : http://amsn.svn.sf.net/viewvc/amsn/trunk/amsn/utils/http/http.tcl?revision=11885 The reason why my fix didn't work is because I had a typo : if {[info exists $state(-command)] } instead of if {[info exists state(-command)] } p.s: I just realized I have some whitespace issues in my code, maybe it's because I did a 'untabify' on the tab, so you may want to do a 'ignore whitespace changes' diff. Sorry. ---------------------------------------------------------------------- Comment By: Alaoui Youness (kakaroto) Date: 2010-01-10 17:50 Message: Hi, I fixed this bug in the latest http 2.7.5 (from core-8-5 branch in CVS). You can get the code here : http://amsn.svn.sf.net/viewvc/amsn/trunk/amsn/utils/http/http.tcl?revision=11885 You can see my changes if you diff it against CVS 1.67.2.9 : http://tcl.cvs.sourceforge.net/viewvc/*checkout*/tcl/tcl/library/http/http.tcl?revision=1.67.2.9&pathrev=core-8-5-branch In theory, no more vwait is used anymore when you do the call to geturl with a -command option. However, the test code previously attached to this bug is still having the same issue, but I have no idea why unfortunately... :( I hope this gets merged upstream. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2911139&group_id=10894 |