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
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
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
> 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
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*
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
> 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
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
> 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
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
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
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
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
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
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
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,
16 matches
Mail list logo