On Fri, Jan 5, 2018 at 11:04 AM, Carsten Haitzler <ras...@rasterman.com> wrote: > On Fri, 5 Jan 2018 10:53:46 -0200 Gustavo Sverzut Barbieri > <barbi...@gmail.com> > said: > >> On Fri, Jan 5, 2018 at 4:04 AM, Carsten Haitzler <ras...@rasterman.com> >> wrote: >> > raster pushed a commit to branch master. >> > >> > http://git.enlightenment.org/core/efl.git/commit/?id=76b837002eaea56b5ecb174bffe284012084dc74 >> > >> > commit 76b837002eaea56b5ecb174bffe284012084dc74 >> > Author: Carsten Haitzler (Rasterman) <ras...@rasterman.com> >> > Date: Fri Jan 5 15:01:02 2018 +0900 >> > >> > efl loop - provide efl namespace versions of begin/end locks on >> > mainloop >> > >> > add efl_main_loop_steal() and efl_main_loop_release() for new efl >> > namespace versiosn of ecore_thread_main_loop_begin() and >> > ecore_thread_main_loop_end(). >> >> > +EAPI int >> > +efl_main_loop_steal(void) >> > +{ >> > + return ecore_thread_main_loop_begin(); >> > +} >> > + >> > +EAPI int >> > +efl_main_loop_release(void) >> > +{ >> > + return ecore_thread_main_loop_end(); >> > +} >> >> since we're targeting multi loop and all, this construct in the new >> API should be multi-loop as well, that is we should have: > > we can't do this multi-loop because this is also tied specifically to > switching > eo domain id's from "thread" to "main" and back. main has one and only one > instance - the mainloop eo id. thread is a thread-local per thread domain so > you can't actually switch to another thread's domain ... except the main loop. > > that's why this is like it is ... :) the "lack of being symmetrical for loops" > irked me but it's an necessary evil unfortunately. > instead for loop to loop i think i'd encourage "sync/async func call" api > stuff > that's on the todo.
well, I can see the main loop blocking a worker thread to ask something to be done... if can't be done, then I'd try to avoid exposing this one. one thread pausing and working on another is also something that can happen in real life scenarios, particularly for poorly designed software that we know will happen. the single issue to get this working is eoid isolation, right? fortunately there is time to improve that before the final release. > see https://phab.enlightenment.org/T5522 > > it has a lot more details in the todo now. > > btw i was wanting to talk about the whole reader/writer stuff using in efl.net > as i am going to have to have a similar io interface from parent to child loop > and back (and also between loops object siblings etc.) > > the whole buffered binbuf slice etc. clarify :-) class name? method? > thing just seems like overly complex > work/effort for just sending a buffer and getting a buffer of bytes to/from a > target object. :( > > what do you think? efl.io.reader.read == read(2) efl.io.writer.write == write(2) efl.io.closer.close == close(2) efl.io.reader.can_read == select(2) + readfds efl.io.writer.can_write == select(2) + writefds they return up-to that amount of bytes, what's there to be read or what can be written without blocking. no buffering done, which makes everything simpler (the implementations are almost 1:1 on unix syscalls). the buffering that was previously replicated in ecore_exe, ecore_con, ecore_ipc... is now moved to outside and can be reused everywhere... as it's based on the reader/writer interfaces. Then ecore_exe in eo will be much, much simpler... and code using ecore_exe in eo will looks very close to efl.net or other efl.io, allows to replace the source or destination with various objects, from different domains (network, file, memory, process...) and everything else will copy. see efl_io_copier_example.c, it's like a netcat-on-steroids... if all you want is to have a buffered input/ouput, you wrap the unbuffered i/o with efl.io.buffered_stream, giving the unbuffered i/o as "inner_io". Then all your reads/writes will be buffered... this is similar to fdopen() + fwrite() and fread(). internally efl.io.buffered_stream keeps binbufs for reads and writes (as fread, fwrite)... you can consume them using efl.io.reader.read(), which will pop stuff from the read buffer... efl.io.writer.write() will push stuff to write buffer. however, since many people want to "peek" at buffer, without really reading from it, you can get the read-only slice, example: - protocol: 4 bytes for integer length, followed by [length] bytes message you can keep the message and check if the 4 bytes are there... and then peek if the rest of the message is there. If it's not, just do nothing... wait it to fill a bit more. once it's all in there, you have 2 options: 1) efl.io.reader.read() 4 bytes, then allocate the [length] array and efl.io.reader.read() that amount of message... this would drain the read binbuff; 2) peek at data using efl.io.buffered_stream.slice.get(), create whatever you need out of the read-only memory, then discard it using efl.io.buffered_stream.discard()... whenever you use 1 or 2 is depending on your implementation, if you need to parse the memory slice and create something else, then likely #2 is more efficient and easier to use, requires no further allocation. >> efl_loop_steal(loop); >> efl_loop_release(loop); >> >> btw, these names are confusing... I like the old ecore version better, >> something like: > > well begin i thought i'd steer clear from because it gets confused with > ecore_main_loop_begin() so easily... :( this realyl does steal the mainloop > (steals a lock then releases it as well as stealing the eoid context). > >> efl_loop_thread_usage_begin(loop); >> efl_loop_thread_usage_end(loop); >> >> or my preference: >> >> efl_loop_thread_pause(loop); >> efl_loop_thread_resume(loop); > > indeed it pauses and resumes... but it ALSO "steals" the eoid context from the > mainloop so your code after the steal acts as if it were in the mainloop eoid > context (it can access mainloop eo objects now). except you and few other core devs, nobody else knows what the hell eoid is, how it works, that's per thread... and they really shouldn't have to know :-) -- 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
