Re: [Edbrowse-dev] JS1
Yes.. and interval isn't even in there at all. I'm not totally clear on how these instances of timeout are used. It seems like it's more of an overall thing, like for the code that manages all the tests. I do not know what that translates into in terms of prevalence or obscurity. Also, note well that the makers of acidtests.org used variable names like kungFuDeathGrip = [e1, e2]; So it's possible that the acidtests has idiosyncracies in the first place... there may have been a lot of LSD going around when they wrote it.. On Sat, 12 Aug 2017, Karl Dahlke wrote: Interesting that you should point this out. My throttle is only valid for intervals, which fire repeatedly. There are no restrictions on timers, which fire only once. So if a timer is scheduled for now + 10ms, then it fires at now + 10ms. However, if that timer schedules another timer for now + 10 ms, then that timer fires in 10 ms, and it continues every 10 ms, and you have found a way around my restriction. In any browser, that's more resource intensive than a 10 ms interval. We're constantly creating objects every 10 ms, which gc must clean up before they accumulate, etc. It's so inefficient I'm guessing nobody would do this, except maybe an acid test. Karl Dahlke Kevin Carhart * 415 225 5306 * The Ten Ninety Nihilists ___ Edbrowse-dev mailing list Edbrowse-dev@lists.the-brannons.com http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
[Edbrowse-dev] JS1
Interesting that you should point this out. My throttle is only valid for intervals, which fire repeatedly. There are no restrictions on timers, which fire only once. So if a timer is scheduled for now + 10ms, then it fires at now + 10ms. However, if that timer schedules another timer for now + 10 ms, then that timer fires in 10 ms, and it continues every 10 ms, and you have found a way around my restriction. In any browser, that's more resource intensive than a 10 ms interval. We're constantly creating objects every 10 ms, which gc must clean up before they accumulate, etc. It's so inefficient I'm guessing nobody would do this, except maybe an acid test. Karl Dahlke ___ Edbrowse-dev mailing list Edbrowse-dev@lists.the-brannons.com http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
[Edbrowse-dev] JS1
> Ok, so how're we going to do all the async js stuff we'll have to start doing > properly soon? Tbh I'm not sure how much I'm attached to the multiple process > idea other than it means js can go pop and we don't... Right. They are orthogonal issues. We're not going to spin off a separate process for every asynchronous thing that the browser might do, it will either be threads or some sort of time share polling, so the separate process was necessary due to the fragility of js, but I think we're fixing that step by step, and when the js side is as solid as the edbrowse side I'd like to fold them back together into one process, which the JS1 variable is a start. I may add some more code over the next week, still under JS1, to simplify the code when it is one process. So many times we can just call a function instead of passing messages around, and we wouldn't even need all those updates when curl data changes etc, so something to work towards. As for the larger question, I don't think I know enough yet to answer. Honestly it makes me nervous to think of making all of edbrowse + duktape threadsafe. Javascrip timers are implemented now, and well tested, e.g. http://www.eklhad.net/async They don't spin on cpu cycles, they actually use timers, but they also signal the main input loop so that everything is serialized. We process what you typed in, or we run the js code associated with a timer, and we're back. There aren't any threads, and it works pretty well. I'm not saying that will work for everything we need to do, I just don't know enough yet, but if it would work for other situations it would be easier. Cheers, Karl Dahlke ___ Edbrowse-dev mailing list Edbrowse-dev@lists.the-brannons.com http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
Re: [Edbrowse-dev] JS1
On Sat, Jul 22, 2017 at 10:49:40PM -0400, Karl Dahlke wrote: > This is either for fun, or for testing, or for the future. I'm not sure. > > export JS1=on Ok, so how're we going to do all the async js stuff we'll have to start doing properly soon? Tbh I'm not sure how much I'm attached to the multiple process idea other than it means js can go pop and we don't... but we *need* to sort out async js soon. Unfortunately websites are becoming increasingly reliant on ajax being genuinely async and that's before we get to websockets etc. With 2 processes it means that we can start with a simple interface with pipes and select as now. With 1 we'll need to do thread-safe programming to make this fly properly. It's not impossible but we'll have to make a bunch of changes to make the existing code properly thread-safe to make that work, or have some way to run duktape in a mode where it only does a certain amount of instructions and use select/poll/some event loop to allow io, comms and js to work together... Honestly I'm not sure what the right design is yet. I've been, unfortunately, rather busy and unable to do much on edbrowse recently so I'm still catching up with things. That being said, this variable, plus the fact that we've made the switch to duktape (well done for that, sorry I ran out of time to help) gives us a mechanism to may be play with some sort of different model for running js. Cheers, Adam. ___ Edbrowse-dev mailing list Edbrowse-dev@lists.the-brannons.com http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
