Skip to content
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

Open
joeyh opened this issue Jun 17, 2012 · 6 comments
Open

porting to Debian kFreeBSD #1

joeyh opened this issue Jun 17, 2012 · 6 comments

Comments

@joeyh
Copy link

joeyh commented Jun 17, 2012

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:

queue/0.1.2.3/kqueue-0.1.2.3$ touch foo; examples/MonitorFile 
KQueueException

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:

 37960 MonitorFile CALL  kqueue
 37960 MonitorFile RET   kqueue 3
...
 37960 MonitorFile CALL  open(0x286fc050,0<><invalid>0,<unused>0)
 37960 MonitorFile NAMI  "foo"
 37960 MonitorFile RET   open 4
...
 37960 MonitorFile CALL  kevent(0x3,0x286fc098,0x1,0x286fc0d8,0x1,0)
 37960 MonitorFile GIO   fd 3 wrote 20 bytes
       0x0000 0400 0000 fcff 1100 7f00 0000 0000 0000  |................|
       0x0010 0000 0000                                |....|

 37960 MonitorFile RET   kevent -1 errno 4 Interrupted system call
 37960 MonitorFile PSIG  SIGALRM caught handler=0x284ff7c0 mask=0x80000000 code= 0x0
 37960 MonitorFile CALL  sigreturn(0xbfbfc300)

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.

@joeyh
Copy link
Author

joeyh commented Jun 17, 2012

For comparison, I wrote a simple C program using kqueue and here's it's ktrace:

 69627 kqdir    CALL  kqueue
 69627 kqdir    RET   kqueue 3
 69627 kqdir    CALL  open(0xbfbfe934,0<><invalid>0,<unused>0)
 69627 kqdir    NAMI  "."
 69627 kqdir    RET   open 4
 69627 kqdir    CALL  kevent(0x3,0xbfbfbf7c,0x1,0xbfbfd37c,0x1,0)
 69627 kqdir    GIO   fd 3 wrote 20 bytes
       0x0000 0400 0000 fcff 1500 0f00 0000 0000 0000  |................|
       0x0010 0000 0000                                |....|

 69627 kqdir    GIO   fd 3 read 20 bytes
       0x0000 0400 0000 fcff 1000 0200 0000 0000 0000  |................|
       0x0010 0000 0000                                |....|

 69627 kqdir    RET   kevent 1

@joeyh
Copy link
Author

joeyh commented Jun 18, 2012

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.

@joeyh
Copy link
Author

joeyh commented Jun 18, 2012

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.

@joeyh
Copy link
Author

joeyh commented Jun 18, 2012

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.

@hesselink
Copy link
Owner

Thanks for looking into this! If you have a patch, I'll gladly accept it.

@joeyh
Copy link
Author

joeyh commented Jun 19, 2012

Erik Hesselink wrote:

Thanks for looking into this! If you have a patch, I'll gladly accept it.

I could put a patch together. Actually, I have developed my own kqueue
library that manages to generate add/delete events for file changes in
a directory tree, recursively. Which would be a good higher-level thing
to put on top of your library. The code is here:
http://source.git-annex.branchable.com/?p=source.git;a=blob;f=Utility/Kqueue.hs;hb=watch
http://source.git-annex.branchable.com/?p=source.git;a=blob;f=Utility/libkqueue.c;hb=watch

see shy jo

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants