however, it seems complex and unfamiliar enough that people still have issues. my impression from that experiment is that since we don't intend to go after anyone anyway, it's best to switch Bisect_ppx to MIT at some point
Orbifx Given Lwt's functionality, I don't think it's critical either.
Hello Anton, I am experiencing some problems when providing a Lwt version of a relatively complex native communication library. In brief, it seams that a blocking I/O call on a function executed as Lwt_schedule.detach blocks anything else from progressing. I've worked around the problem, but I'd like to get to the bottom of this and understand what is causing this strange interaction. To this end, is there any place where I can see the things that a native library may do or don't. Like masking signals, etc. Thanks very much in advance!
great :) i assume you were using Lwt_preemptive.detach. there is nothing in Lwt itself that should prevent the thread from progressing, modulo any bugs in Lwt. Lwt_preemptive is ultimately a wrapper around ocaml's own threads. the biggest gotcha in it is probably that the default thread limit is 4 or something, which is not enough for many uses. we definitely want to document any other likely snags, so i'll be happy to look at that link :)
@bruce-ricard, @copy makes a good suggestion with alcotest :) here's a link: https://github.com/mirage/alcotest
@bruce-ricard we have a list of libraries you might want to use with Lwt in the README, perhaps we need to move it higher though https://github.com/ocsigen/lwt#libraries-to-use-with-lwt
and if you find something else that should be on there, please tell us about it/open a PR :)
I feel like that might be a good thing to put there: https://ocsigen.org/lwt/2.7.0/manual/manual A short section about testing with a reference to alcotest.
Basically what I want is a read_lines function, which starts reading from the end of the file.
@StrykerKKD sorry for the delayed reply (was away). reading files backwards is usually not so easy. you can either read the whole file normally, split it into lines, and replay the lines in reverse order, or read chunks of the file, starting from the end, into a buffer, and extract lines from there
I think Lwt is out of truly easy issues. you may want to browse around other projects that you use/know of
you could of course try something more complicated in Lwt, or try publishing some code of your own :)
Is there something in particular I should look at?
Thank you for all your help!
slekaml Oh sorry I mistook this chan for the chan of the people who took the ocaml mooc
The above code blocks at flush (FLUSH-1.1b is printed, but not FLUSH-1.1c)
BUT, this occurs in a very big program, involving ocsigenserver, eliom, various libraries of mine. Of course, I am unable to reproduce it in a small example.
Question : how can possibly flush stderr block ?
Hint : it really blocks the process. CTRL+C has no effect on the running process.
Other hint : I have a periodic (debug) task which prints dots :
let rec loop () =
Lwt_io.printf "." ;%lwt
Lwt_unix.sleep 0.1 ;%lwt
loop ()As the FLUSH blocks, this loop may block or not (same executable launched a couple of times : once it prints dots repeatedly, but FLUSH is blocked, once it does not print dots and FLUSH is also blocked).
Finally, I am using lwt.4.3.0 (opam pin --dev-repo), ocaml 4.08.1
@lebotlan I'm not sure why it would hang like that. Looking at the code, it seems like
Lwt_bytes.write would have to hang, emptying the internal Lwt_io channel buffer. I suggest to either narrow the case as much as you can, by deleting huge chunks of code from a second copy of your project, or to put lwt as a sibling project of yours into a dune workspace and instrument Lwt_io with prints to get a better idea of what is going on
as for gitter, it still sends me notifications :) though issues is easier, because the notifications are immediate, whereas gitter delays them. i may disable gitter because of that
@aantron Thank you for your reply (I wasn't sure this deserved an issue :) )
I'll follow your advice (and also try some other hacks that came to my mind).
For the moment, the bug has disappeared (also I am pretty sure I have not recompiled, only changed the environment - IP, dual screen). So it seems non-deterministic.
My guess is that it is some sort of race-condition, which might be difficult to reproduce in a small program. Anyway, I'll see what I can do.
also check this issue, which has just been solved in
master: ocsigen/lwt#704. it affected Lwt programs that called fork, on glibc > 2.24 (not sure exactly which version of glibc introduced the problem). if you used opam pin --dev-repo, you are likely not using exactly lwt 4.3.0. to be sure about which commit you are using, do a normal git clone, check git log, and then do opam pin add lwt .