On Fri, 23 Dec 2016 12:50:34 +0100 Vincent Torri <vincent.to...@gmail.com> said:
> On Fri, Dec 23, 2016 at 11:23 AM, Andrii Kroitor <an.kroi...@samsung.com> > wrote: > > > > On 23.12.16 06:35, Vincent Torri wrote: > >> hey > >> > >> i don't like the idea of getc/ungetc in the thread, imho it's a bad hack > >> you do that for ethumb_slave, i guess, but i think that the wait for > >> input should be in ethumb slave, with a thread and ReadConsole(). and > >> not the hack you did > >> > >> Vincent > >> > >> ------------------------------------------------------------------------------ > >> Developer Access Program for Intel Xeon Phi Processors > >> Access to Intel Xeon Phi processor-based developer platforms. > >> With one year of Intel Parallel Studio XE. > >> Training and support from Colfax. > >> Order your platform today.http://sdm.link/intel > >> _______________________________________________ > >> enlightenment-devel mailing list > >> enlightenment-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > >> > > I'm also not 100% happy with getc/ungetc thread, but this was the only > > solution, that works in all cases. > > I have tried various approaches, but all other are failing to wait for > > input correctly at least in one of the following cases: > > 1. direct run and input from console > > 2. debug run and input from console (yep, this is somehow different from > > case 1 :( ) > > 3. redirected stdin input ( "app.exe <in.txt" ) > > 4. direct run within pipeline ( "some_other_app.exe | app.exe" ) > > 5. run as subprocess with stdin replaced with pipe from parent (i.e. > > parent uses ecore_exe) > > > > If I remember it right ReadConsole will fail in cases 3-5. > > > > So if you find some better solution that will work in all this cases it > > will be great. the POINT of moving it to a thread and just using getc/gets was to be portable and not have #ifdef'd per os solutions. > 1) try with filtering the console mode and flushing the buffer in > ethumb_slave: > > DWORD old_mode; > HANDLE stdin_handle; > stdin_handle = GetStdHandle(STD_INPUT_HANDLE); > GetConsoleMode(, &old_mode); > mode = oldmode ^ ENABLE_MOUSE_INPUT ^ ENABLE_WINDOW_INPUT; > SetConsoleMode(stdin_handle, mode); > FlushConsoleInputBuffer(stdin_handle); > > then you should be able to wait on stdin_handle after that. > > anyway, ReadConsoleInput() should be used intead of read() > > you should restore the old mode to restore it at the end : > > SetConsoleMode(stdin_handle, old_mode); > > 2) try to redirect console input handle (not tested): > > HANDLE stdin_handle; > int fd; > FILE *fp; > > stdin_handle = GetStdHandle(STD_INPUT_HANDLE); > fd = _open_osfhandle((intptr_t)stdin_handle, _O_TEXT); > fp = _fdopen(fd, "r"); > *stdin = *fp; > setvbuf(stdin, NULL, _IONBF, 0); > > 3) there is another possibility : using WSAWaitForMultipleEvents(), > but that would mean another way to add a handler in ecore_main.c. > > note that it would save my day for another thing i'am working on. > > > > I disagree with you about this code placement. My point is that as many > > as possible platform-dependent things should be in libraries rather than > > in client-side code. > > it's not possible to have everything platform dependant. I know some > stuff that will never be platform dependant, by the very nature of > Windows. > > but I think that the ecore_exe way should be the way to go, even if it > needs modifications > > Vincent > > > -- > > *Best Regards, > > Andrii Kroitor > > * Engineer, Tizen Platform Lab > > > > Samsung R&D Institute Ukraine > > 57, Lva Tolstogo St., Kyiv 01032, Ukraine > > email: an.kroi...@samsung.com <mailto:an.kroi...@samsung.com> > > > > > > ------------------------------------------------------------------------------ > > Developer Access Program for Intel Xeon Phi Processors > > Access to Intel Xeon Phi processor-based developer platforms. > > With one year of Intel Parallel Studio XE. > > Training and support from Colfax. > > Order your platform today.http://sdm.link/intel > > _______________________________________________ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > ------------------------------------------------------------------------------ > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today.http://sdm.link/intel > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/intel _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
