Re: [PATCH v2] implement full-blown select(2) for winsock

2008-10-04 Thread Bruno Haible
Hi Paolo, > > For reference, here is the code that is in use in clisp to detect whether > > reading from a handle would hang or return immediately. The deal with > > ENABLE_LINE_INPUT is that PeekConsoleInput will say "yes there is something > > is available" as soon as the user has started typing

Re: [PATCH v2] implement full-blown select(2) for winsock

2008-10-01 Thread Paolo Bonzini
Bruno Haible wrote: > Paolo Bonzini wrote: >> I agree, but it seems like pipe WaitForSingleObject is broken. You'd >> need a thread polling with PeekNamedPipe, or a busy-waiting loop in the >> main thread altogether. > > Maybe we need to reset the pipe from "signaled" to "non-signaled" state > af

Re: [PATCH v2] implement full-blown select(2) for winsock

2008-10-01 Thread Bruno Haible
Paolo Bonzini wrote: > I agree, but it seems like pipe WaitForSingleObject is broken. You'd > need a thread polling with PeekNamedPipe, or a busy-waiting loop in the > main thread altogether. Maybe we need to reset the pipe from "signaled" to "non-signaled" state after [Msg]WaitFor..Objects retur

Re: [PATCH v2] implement full-blown select(2) for winsock

2008-10-01 Thread Paolo Bonzini
> No, please. I don`t need sockets. For communication with a subprocess, all > I need is a pipe. Sockets would be an overkill for that. I agree, but it seems like pipe WaitForSingleObject is broken. You'd need a thread polling with PeekNamedPipe, or a busy-waiting loop in the main thread altoget

Re: [PATCH v2] implement full-blown select(2) for winsock

2008-09-30 Thread Bruno Haible
Hello Paolo, > > select() on a regular file > > should return "ready" always, no? There's no need to even call > > WaitForSingleObject on this one, IMO. > > Right, Patch applied. > can you do the same for poll() too? I fear I can't: I don't understand the differences between the various POLL*

Re: [PATCH v2] implement full-blown select(2) for winsock

2008-09-30 Thread Bruno Haible
Hello Paolo, > > How about adding an assertion like this? > > > > + if (!timeout && rc == 0) > > + abort (); > > But wouldn't this trigger in your case, thus aborting select() and poll()? Yes it would currently abort in select(). But it would force us to fix the problem in a way that does

Re: [PATCH v2] implement full-blown select(2) for winsock

2008-09-29 Thread Paolo Bonzini
> How about adding an assertion like this? > > + if (!timeout && rc == 0) > + abort (); But wouldn't this trigger in your case, thus aborting select() and poll()? > But I am afraid to propose this as a fix, because this is busy-looping, and > the purpose of select() is to avoid busy-looping

Re: [PATCH v2] implement full-blown select(2) for winsock

2008-09-29 Thread Paolo Bonzini
Bruno Haible wrote: > Hi Paolo, > > Thank you for providing this select() implementation! With it, I can now make > 'msgfilter' work on mingw. > > Here's a patch for a possible optimization: select() on a regular file > should return "ready" always, no? There's no need to even call > WaitForSingl

Re: [PATCH v2] implement full-blown select(2) for winsock

2008-09-29 Thread Bruno Haible
> handle console handles (e.g. stdin) For reference, here is the code that is in use in clisp to detect whether reading from a handle would hang or return immediately. The deal with ENABLE_LINE_INPUT is that PeekConsoleInput will say "yes there is something is available" as soon as the user has st

Re: [PATCH v2] implement full-blown select(2) for winsock

2008-09-29 Thread Bruno Haible
Hi Paolo, In some cases, the select() emulation returns 0 even when no timeout was specified. I use it in msgfilter for communication with a subprocess. - Initially I call select() on 2 file descriptors: an fd for parent<-child and another for child->parent writing. select() reports that writin

Re: [PATCH v2] implement full-blown select(2) for winsock

2008-09-29 Thread Bruno Haible
Hi Paolo, Thank you for providing this select() implementation! With it, I can now make 'msgfilter' work on mingw. Here's a patch for a possible optimization: select() on a regular file should return "ready" always, no? There's no need to even call WaitForSingleObject on this one, IMO. Proposed p

Re: [PATCH v2] implement full-blown select(2) for winsock

2008-09-28 Thread Bruno Haible
Hi Paolo, > 2008-09-23 Paolo Bonzini <[EMAIL PROTECTED]> > > * m4/sys_select_h.m4: Compile lib/winsock-select.c if WinSock is used. > Require gl_HEADER_SYS_SOCKET. On HP-UX, which has but no , I get a syntax error because the generated sys/select.h file has a lone #if, because HAV

Re: [PATCH v2] implement full-blown select(2) for winsock

2008-09-23 Thread Simon Josefsson
Paolo Bonzini <[EMAIL PROTECTED]> writes: > Simon Josefsson wrote: >> Paolo Bonzini <[EMAIL PROTECTED]> writes: >> >>> This revised patch includes the select(2) wrapper in sys_select, >>> not sys_socket. This makes sense given the very purpose of the >>> wrapper -- which is to let the client use

Re: [PATCH v2] implement full-blown select(2) for winsock

2008-09-23 Thread Paolo Bonzini
Simon Josefsson wrote: > Paolo Bonzini <[EMAIL PROTECTED]> writes: > >> This revised patch includes the select(2) wrapper in sys_select, >> not sys_socket. This makes sense given the very purpose of the >> wrapper -- which is to let the client use select for other descriptor >> types than socket

Re: [PATCH v2] implement full-blown select(2) for winsock

2008-09-23 Thread Simon Josefsson
Paolo Bonzini <[EMAIL PROTECTED]> writes: > This revised patch includes the select(2) wrapper in sys_select, > not sys_socket. This makes sense given the very purpose of the > wrapper -- which is to let the client use select for other descriptor > types than socket handles. Btw, if you didn't li

[PATCH v2] implement full-blown select(2) for winsock

2008-09-23 Thread Paolo Bonzini
This revised patch includes the select(2) wrapper in sys_select, not sys_socket. This makes sense given the very purpose of the wrapper -- which is to let the client use select for other descriptor types than socket handles. I do believe that the code belongs in the generic "header file" modules,