there are some errors in the pipe names in ecore_con on Windows, so I think that they must be fixed first
Vincent On Mon, Mar 27, 2017 at 9:44 PM, Gustavo Sverzut Barbieri < [email protected]> wrote: > Hi all, > > Please check my branch: devs/barbieri/efl_net_socket_windows2 > https://git.enlightenment.org/core/efl.git/log/?h=devs/ > barbieri/efl_net_socket_windows2 > > This is what I plan to merge, I did tests using wine > (src/examples/ecore) and it seems to work, please test on real windows > machine and report problems please. > > PS: some tests use ecore_main_fd_handler_add(STDIN_FILENO, > ECORE_FD_READ, _on_stdin, NULL, NULL, NULL); to read from stdin, at > least on wine this is not working as expected, in these tests I'm > simulating by calling _on_stdin() from an ecore_job... > > BR, > > On Fri, Mar 24, 2017 at 10:20 AM, Gustavo Sverzut Barbieri > <[email protected]> wrote: > > On Fri, Mar 24, 2017 at 6:09 AM, Vincent Torri <[email protected]> > wrote: > > [...] > >>>> TL;DR: we'll never benefit from the thread pool benefits. > >>> > >>> it will if we have a lot of use of connections using ecore_con_local > >>> or ecore_ipc > >> > >> also, it does not consume HANDLE's, > > > > what you mean? > > > > > >> contrary to what you will use with > >> the design you want to choose (which is btw my first implementation of > >> ecore_con_local, you're re-writing it...) > > > > Yes, I checked the old win32 local file when I did some grep... but > > it's slightly different as it uses the hEvent instead of notifying on > > our own with SetEvent(). > > > > > >> and will be faster. The > >> Windows port is already largely slower than the linux one. I've chosen > >> I/O completion port for that very reason > > > > here is the part that I think I couldn't explain, it doesn't matter > > the port speed if the user is not sending stuff to it. > > > > it's like having a 1Gbps network but the card is only capable of 10bmps. > > > > this is because we must go back to main thread to get more data to > > send. Same for read, we only read up to BUFSIZE (I'm using 16kb), then > > we call the user... until that is done, the kernel will idle... > > > > -- > > Gustavo Sverzut Barbieri > > -------------------------------------- > > Mobile: +55 (16) 99354-9890 > > > > -- > 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
