> Hmm. Kqueue should be thread-safe in that it's a system call, but I can't > speak to the safety of various arguments/parameters. I don't know if > linuxthreads tries to provide locking around file descriptors and might > have reference problems if kqueue were held over a call to close(), but it > could be kqueue will "just work" with linuxthreads. Do calls like > select()/poll() require thread-safe versions in linuxthreads?
Yeah, select/poll is not needed, but the thing is that my app, which I just changed from pthreads to linuxthreads, did all ok, launched threads and all, but it crashed when running kevent() and all the referrences it gave to kevent() were fine. > Do you have an outstanding PR on the LSI problem, and/or a stack trace for > the trap? In the past, our LSI drivers have been fairly well maintained > on the LSI side. I can certainly try shaking some branches and see if > anything falls down, if there's a detailed bug report I can point at. I have no PR nor do I have a stack trace for the trap right now. How would I exactly get a stack trace of the trap? It happends when booting from the 5.2-beta cd-rom. Let me know when you need from me and I'll get all that. The box is at a hosting provider so I'll have to get the info from them. > I know some work has been done relating to this problem at Yahoo, > especially relating to disk fragmentation resulting from allocation using > mmap on sparse files. You might want to try posting about this problem on > freebsd-fs or freebsd-current and see if you manage to hook someone who's > been looking at this. Thanks, I'll give that a try. Fabian _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"