New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
VM-threads prevent unblocked I/O #2873
Comments
Comment author: administrator Dear Markus,
You're indeed looking for trouble. VM threads use non-blocking I/O May I suggest you think again at what you're trying to achieve?
I'm working on this issue, which is really not as bad as Raffalli Best wishes,
|
Comment author: administrator VM threads cannot (reasonably) be made compatible with non-blocking I/O |
Comment author: administrator Dear Xavier, On Mon, 28 Jun 2004, Xavier Leroy wrote:
Yes, that's the normal case. In my case I don't need non-blocking I/O I think it should not be too difficult to handle non-blocking I/O with I have written a short example of a workaround now - just in case somebody open Unix let watchdog time v = let timed_sync time v ev = let uses_posix_threads = let unblocked_really_input ic buf ofs len =
|
Original bug ID: 2873
Reporter: administrator
Status: closed
Resolution: won't fix
Priority: normal
Severity: feature
Category: ~DO NOT USE (was: OCaml general)
Bug description
Hi,
VM-threads obviously do not allow me to use unblocked I/O on sockets.
If I set a timeout on some socket, e.g.
setsockopt_float sock SO_SNDTIMEO 3.141
then the timeout ("Sys_blocked_io" or Unix_error EAGAIN/EWOULDBLOCK)
will be caught in the VM-thread specific pervasives.ml or unix.ml,
and then the operation blocks (or loops).
Unfortunately, since POSIX-threads, which do not have a problem with this,
currently seem to cause problems on Linux 2.6, this is quite annoying.
What else could I do without resorting to signficantly more complex I/O
without threads?
The functions "wait_timed_read" and "wait_timed_write" are not
particularly helpful, because they only tell me whether some characters
can be written, which does not imply that all of them can - in which
case the I/O-operation blocks again.
Best regards,
Markus
--
Markus Mottl http://www.oefai.at/~markus markus@oefai.at
The text was updated successfully, but these errors were encountered: