On Sat, Mar 3, 2018 at 2:02 AM, Carsten Haitzler <ras...@rasterman.com> wrote: > I just pushed: > > eb0b826776b60e0d97218242a5c285d146fb6f3b > > https://git.enlightenment.org/core/efl.git/commit/?id=1bdd9e4dd15fc27da43b50fd29bfb1b0b30ef6bd > > I wrote up a high level design document and description here for an idea of > how > it works: > > https://phab.enlightenment.org/w/efl-loops-threads/ > > I'm busy filling that document out a bit, but the core essentials are there. > > There are some details like loop having an exit eina value vs task having a > simple int exit code (i'm sticking to this because it is what processes do, > it's simple and its universally supported between processes, unlike an eina > value). yes - it simplifies threads to only having int exit codes, but the > simplicity of the design is what I'm going for. threads like executeables have > full bytestream I/O for more complex data interchange. So there probably needs > to be a bit of adjusting here and there to remove duplication. The Arguments > event delivers arguments in an array, but the task object also stores > arguments > too permanently. Do we need to double-up the information? So a few small > things > like this. > > I've given this design a lot of thought and what I have here I think is clean > and neat, tidy and fairly simple. It actually does work. I have tested it of > course. But please have a look and let me know what you think. Are there some > major defects in the design and idea? I know we can expand this in future with > more controls (I have no pause/resume controls in the task interface but there > should be. For processes use SIGSTOP/CONT and for threads a co-operative > request on the control line). The internals could be better. I use pipes and > this eats up a lot of FD's for the threads where I could use socketpairs > instead. I have a separate control pipe in/out from I/O in/out where i could > multiplex on the same socketpair. Currently we run out of FD's (after > about 240 threads running at once because they eat up 8 FD's per thread. The > Efl.Io code across the classes is a lot of copy & paste... And I don't have > anything to change priority of a thread once it has run (no eina API for this > - > needs to be added). > > I'm not that happy though with Efl.Io and the sheer amount of code needed to > deal with it. Even as a user of the API. > > Anyway - comments, thoughts, etc. etc. ?
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. 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. 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. -- 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel