On Fri, Feb 3, 2017 at 4:01 AM, Carsten Haitzler <[email protected]> wrote: > raster pushed a commit to branch master. > > http://git.enlightenment.org/core/efl.git/commit/?id=eab798c753e72eece526ceccf3c9beb441b5f5ff > > commit eab798c753e72eece526ceccf3c9beb441b5f5ff > Author: Carsten Haitzler (Rasterman) <[email protected]> > Date: Fri Feb 3 14:57:49 2017 +0900 > > ecore_con/efl_net - dedicated threads for network i/o not from the pool > > so ecore_con/efl_net were using the standard ecore_thread thread pool > for doing things like dns lookups
this is true > (that can take multiple minutes until timeouts) this is unlikely > and actual http transactions. this is false. CURL itself does the HTTP transactions using our main loop by calling back efl_net_dialer_http.c to register/unregister/modify the fd that is being modified. > similarly they can block > thread workers for long periods or indefinitely thus basically > blocking the whole eocre_thread pool and stopping others from sharing > it. how big is the thread pool? I hope it's a dynamic size and will not simply serialize everything into one/two threads. > the best solution we have right now is to bypass the thread pool > queue and have dedicated threads for these actions. what we should > have is a dedicated thread pool with each thread taking on N > connections (via select etc.) and the ability to create and destroy > thread pools for specific tasks so you can separate the work out from > other work. but that is basically a redesign of our thread pool infra > so let's do the quick solution here until that day comes. not sure about this. If I go and try to use that in efl_net, it will always go wrong: - If I hope the guy is doing regular desktop app that randomly need 1-2 remote resources, that's like 1-2 lookups for the whole lifetime, so likely a single thread for the whole application is good enough. - if I think that's going to be used by multi tab browser doing prefetch and parallel resources, that's like 100's lookups for each tab, then 50+ threads would be desirable. - If I think the guy is writing a server utility that may execute hundreds of thousands transactions per second, then it's closer to that order. That said, my bet is that EFL would dynamically grow and shrink the pool using some heuristic, like: - queue at most 1-2 requests in a thread, then spawn a new thread; - if thread is idle for X seconds, exit. It would be even better if the requests could be migrated from threads (or pop'ed from a common queue), so in the case one job/func takes too much to execute we don't wait for queued funcs if we have other idle threads. > this partially addresses D4640 > > a dedicated thread per image load though is going to be a lot nastier... > --- > src/lib/ecore_con/ecore_con.c | 9 +++++---- > src/lib/ecore_con/efl_net_dialer_http.c | 9 +++++---- > 2 files changed, 10 insertions(+), 8 deletions(-) > > diff --git a/src/lib/ecore_con/ecore_con.c b/src/lib/ecore_con/ecore_con.c > index dd641da..35eb4d0 100644 > --- a/src/lib/ecore_con/ecore_con.c > +++ b/src/lib/ecore_con/ecore_con.c > @@ -703,10 +703,11 @@ efl_net_ip_resolve_async_new(const char *host, const > char *port, const struct ad > > d->result = NULL; > > - return ecore_thread_run(_efl_net_ip_resolve_async_run, > - _efl_net_ip_resolve_async_end, > - _efl_net_ip_resolve_async_cancel, > - d); > + return ecore_thread_feedback_run(_efl_net_ip_resolve_async_run, > + NULL, > + _efl_net_ip_resolve_async_end, > + _efl_net_ip_resolve_async_cancel, > + d, EINA_TRUE); > > failed_hints: > free(d->port); > diff --git a/src/lib/ecore_con/efl_net_dialer_http.c > b/src/lib/ecore_con/efl_net_dialer_http.c > index 2454c72..6c4a463 100644 > --- a/src/lib/ecore_con/efl_net_dialer_http.c > +++ b/src/lib/ecore_con/efl_net_dialer_http.c > @@ -1407,10 +1407,11 @@ _efl_net_dialer_http_efl_net_dialer_dial(Eo *o, > Efl_Net_Dialer_Http_Data *pd, co > > ctx->o = o; > > - pd->libproxy_thread = > ecore_thread_run(_efl_net_dialer_http_libproxy_run, > - > _efl_net_dialer_http_libproxy_end, > - > _efl_net_dialer_http_libproxy_cancel, > - ctx); > + pd->libproxy_thread = > ecore_thread_feedback_run(_efl_net_dialer_http_libproxy_run, > + NULL, > + > _efl_net_dialer_http_libproxy_end, > + > _efl_net_dialer_http_libproxy_cancel, > + ctx, EINA_TRUE); this needs to go, I said to Cedric I'll work on it. the libproxy thread had a reason to exist when it was using libproxy directly. Now that it uses another process, then the reason ceases and we can be async directly on top of ecore_exe. -- Gustavo Sverzut Barbieri -------------------------------------- Mobile: +55 (16) 99354-9890 ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
