mozilla :: #pdfjs

26 May 2017
00:38yuryrobwu_nl: hi, I need new trick :) I found out that fetch()/xhr just stop and loading anything thus blocking resolution
00:39yurymy guess it might be a tcp port issue?
00:40yury\stops loading
00:41yuryfetch() gives request by nothing follows req.text() resolution
00:50yuryor maybe promise is GC'd
01:10yuryrobwu_nl: I see
01:13yurynetwork monitor shows 200 and colorspace content
16:50yurybdahl: good morning
16:50bdahlyury: good morning
16:50yuryso far chrome's fetch creeps out on us
16:51yurymore files we feed through it, more probability it to fail
16:52yurymaybe it's just a promises
16:53yurye.g. promise was GC'ed
16:54* yury only wonders why that's happening in es6 mode
16:55bdahlyury: do you see the fetch hang in the network monitor?
16:55yuryit's 200 there
16:56bdahlbut no promise resolution?
16:57* yury needs magic
16:57yuryand hack
16:58bdahlyury: what if workers are off?
16:59yurythat's not a hack
16:59bdahli'm just wondering if it always works then
16:59yuryit will load only once for test driver
17:03yurythat's getting to thinking if fetch or Promise has such defect we are in big trouble
18:06mukulyury: hi
18:07mukulI am having tough time finding potential issue here:
18:07mukulI think it is related to some chrome bug
18:08mukulfailing only on latest version of chrome
18:09yurythere might be some timing/racing issues
18:09yuryso be carefull when you change tests
18:09yurysee if it's just extra pull because close was not sent in time
18:10yurythat might be okay or not, careful analyze the issue
18:11mukulyeah, right. I also think it is something related to timing.
18:12mukulbut increasing sleep does not change anything
18:14mukulwhen i am trying to log cancel here:
18:15mukulIt is giving me `log = 012pc` here:
18:15mukulfor sleep(10)
18:16yuryas I said pull and close can collide in mid air
18:16yurytheoretically it's possible
18:16mukulbut it should throw error
18:17mukulas we are trying to access sink after delete ...
18:17yurynot sure why yet
18:17yuryit's more complex than that
18:18mukulor do we have any lag in messageHandler?
18:18yurystream on main thread decides that pull is needed
18:18yuryour handler decideds that it's end of stream, and sends close at the same time
18:19yurynothing wrong with it, it's the way how it's handled
18:19yurymukul: is it the case I decribed above?
18:21yuryif it is, we probably need to anticipate this one pull and ignore it
18:21yurythere are many ways to solve it though
18:23mukulI thought this pull is called by enqueue method of ReadableStream, just to fill it's internal queue
18:23mukulas defined here
18:24yuryhow it's related to what is going on the worker side?
18:26mukulnot sure, but calling does not call pull actually
18:27mukuland hence we are not getting any error for sink is deleted
18:28yurymukul: can you log every call for underlyingSource and controller objects (on main side)
18:28yurylet's log stuff only on main thread
18:29* yury needs only these messages to check if it is the case he descrived
18:30mukulyou mean instead of tracking log on worker we track it on main side, right?
18:31mukulor just console.log for checking calls for underlyingSource and controller
18:32yurythe latter
18:32mukuli tried earlier to log inside pull, and it is calling after 1st enqueue
18:33mukulthat mean it is calling to fill internal queue of stream
18:33mukulas data length is 4 and desiredSize is 8
18:34mukulyury: When we have `highWaterMark = 10`, then close is called immediately(because ready is resolved all time)
18:35yuryour tracking of desizeredSize on worker side is irrevant to the pull() calls to underlineSource on main side
18:35mukuland we are getting error as sink is deleted
18:36yuryand this error raise when?
18:36mukulwhen desiredSize(or highWaterMark) is 10
18:36yurywhen pull message is send after we closed the stream?
18:37mukulyes right.
18:37mukulclosing stream delete sink and controller
18:38yurymukul: can you synchronosly notify from worker controller on the main thread?
18:38yuryanwser will be 'no'
18:39yurypull can be called
18:39yurysince we are doing async communication
18:40yurymukul: do you have logs to confirm that?
18:41mukulokay, let me try
18:41yurythe solution will be to ignore any pull coming from the main thread if close was called
18:42yurybut only in this case
26 May 2017
Last message: 3 minutes and 33 seconds ago