On March 5, 2018 6:00 AM, Gustavo Sverzut Barbieri <barbi...@gmail.com> wrote:
<snip>
> Well, I already mentioned this to you in irc, but replying here just
> to make my point:
>
> I think the design is upside down, trying to make life easier at some
> point resulted in messy at the other side.
>
> okay, call it a task, work for both process and threads, the hope is
> to facilitate "switch from threads to process, and vice versa", but
> we're getting the worst part of each it seems.
>
> ie: most thread usage is about sending shared memory back and forth,
> after all the benefit of threads is just that: shared memory. What we
> got? argv + int, useless for real life threads.
>
> solution? "stdio" for threads... you can send/receive I/O, done with
> pipes, like it would be for processes.
>
> I really, really don't like that design. To me threads should be
> exposed as such, with pointer argument and result... if you wish to
> make it easier, you could "box" it someway, like eina_value... or just
> let the traditional "void *pointer". But that's fundamental, say for
> Python bindings to use threads, you want to send PyObject pointer to
> the thread, that object will contain the information to callback the
> user (the user's Python-callable). And for most usages as well, like
> sending file info to be opened/decoded, etc.
I do second you completely Gustavo. I have been raising my discontent with this
design for a long time now and fully agree with your point here.
> thread I/O, while useful in some cases, I don't see why they should
> always exist. They should be optional, and as such they should be
> created explicitly.
Agreed.
> Last but not least, I'd expose the stack just like in the OS, to not
> make confusion:
>
> - Application ("the binary") -> Processes -> Threads -> main loop
>
> you can present "getters" that make it easier to access (ie: main loop
> "get" application, in addition to "get parent" which would return the
> thread).
>
> But mixing stuff "in the hope to make it easier" it not, it's just
> making things more complicated... ALSO note that the developer that
> would use this kind of API is "not the average developer", these don't
> mess with such low level primitives. The developer that is likely to
> use these primitives will say "what the fuck is this? I'm used to
> processes and threads, these guys just messed it up".
>
> I'm in favor of interfaces for things that are the same, so if the
> methods in process and threads share the same concept, behavior and
> parameters, make them an interface... when switching from process x
> threads one doesn't need to "sed" everything. However, definitely
> constructors are NOT the same concept, behavior or parameters, thus
> not part of the interface.
I would add that this thread model doesn't satisfy any of the use case we
ourself have. For example :
- Ector: use thread to offload CPU and memory heavy task to another thread. The
simple change to BFL has slowed us down. Now, if we do have to
serialize/unserialize everything ? I have already my bet on the result.
- Evas async renderer: same case as Ector. Nobody might remember, but at the
beginning it was really slower, because of the memory copy that was done and it
had to be removed. If we were to use this new infrastructure, it would lead to
be back to a slower solution.
- Eio: we offload the io and the content generation from another thread. Even
unecessary function call do significantly slow us down while listing a
directory. That is why we are grouping things in array to avoid this function
call. I do not expect things to get better with the above proposal.
- Efl_Net: the design of the interfaces allow for moving an object to another
loop, but because we can't transfert a socket to another loop, we can't use
that. It means that we can not do any load balancing from the main loop. We can
use Efl.Io to redirect traffic to another thread, but it will always require a
wake up and work in the main loop.
If it doesn't solve our own problem, I am not convinced it will be solving
anyone problem.
Cedric
------------------------------------------------------------------------------
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
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
