-
Notifications
You must be signed in to change notification settings - Fork 11
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
porting to Debian kFreeBSD #1
Comments
For comparison, I wrote a simple C program using kqueue and here's it's ktrace:
|
Well, I wrote my own C function that uses kqueue, verified it worked in a standalone C program, and then tried to call it via the FFI from Haskell, and I see the same SIGALARM problem in its ktrace. So this seems to be something the GHC runtime is doing. |
Alright, this SIGALARM problem can be worked around with -RTS -V0 But, at least for Debian kFreeBSD, a better fix seems to be to check if kevent() returns -1 with errno == EINTR. If so, just retry that kevent call. When I do this it works. I still don't know if this SIGALARM problem is specific to Debian kFreeBSD. It's possible that the regular BSD libc automatically retries kevent calls when the syscall is interrupted, and that the Debian glibc I'm using omits this. |
According to #haskell, this is a change in ghc 7.2+. So this SIGALARM problem probably will affect this library on real BSDs as well. |
Thanks for looking into this! If you have a patch, I'll gladly accept it. |
Erik Hesselink wrote:
I could put a patch together. Actually, I have developed my own kqueue see shy jo |
Debian's kFreeBSD port is the KfreeBSD kernel + GNU userland. It supports the kevent syscall the same as regular FreeBSD. I've tried to port kqueue to it, and got it to build fairly easily.
I had to adjust some types in data KEvent: ident needs to be a CUInt and data_ a CInt.
I also had to comment out the NOTE_SIGNAL and NOTE_REAP as they were not in the system's headers.
With those minor changes, I have a clean compile of your library.
But, examples don't work:
Since this could happen if there are too many events being returned, I also tried increasing the number of events to receive, which didn't help.
ktrace shows this happening:
As far as I can see, the parameters passed to kevent() look right.. kqueue 3, 0 timeout, 1 event watched, 1 buffer..
I guess this points to a problem in the KEvent data structure.
The text was updated successfully, but these errors were encountered: