Re: msleep() on recursivly locked mutexes
On Thu, 26 Apr 2007, Julian Elischer wrote: Further the idea that holding a mutex "except for when we sleep" is a generally bright idea is also a bit odd to me.. If you hold a mutex and release it during sleep you probably should invalidate all assumptions you made during the period before you slept as whatever you were protecting has possibly been raped while you slept. I have seen too many instances where people just called msleep and dropped the mutex they held, picked it up again on wakeup, and then blithely continued on without checking what happened while they were asleep. And interesting observation here is that FreeBSD 4.x and earlier were actually rife with exactly this sort of race condition, exercised only when under kernel memory pressure because sleeping occurred only then. The explicit locking model we use now makes these races larger due increased concurrency (preemption, parallelism, etc), but also makes our assertion model stronger. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: msleep() on recursivly locked mutexes
On Fri, 27 Apr 2007, Julian Elischer wrote: Basically you shouldn't have a recursed mutex FULL STOP. We have a couple of instances in the kernel where we allow a mutex to recurse, but they had to be hard fought, and the general rule is "Don't". If you are recursing on a mutex you need to switch to some other method of doing things. e.g. reference counts, turnstiles, whatever.. use the mutex to create these but don't hold the mutex for long enough to need to recurse on it. A mutex should generally lock, dash-in and work, unlock. We have some cases where that is not true, but we are trying to get rid of them, not add more. Most of these instances have to do with legacy code and data structures that involve high levels of code recursion and reentrance. This is frequently an unreliable way to organize code anyway, and often involves other bugs that are less visible. Over time, it's my hope that we can eliminate quite a few sources of remaining lock recursion, but there are some tricky cases involving repeated callbacks between layers that make that harder. For example, in the socket/network pcb relationship, there's a lack of clarity on which side drives the overlapping state machines present in both sets of data structures. Over time, we're migrating towards a model in which the socket infrastructure is more of a "library" in service to network protocols that will drive the actual transitions, but in the mean time, lock recursion is required. For any significantly rewritten or new code, I would expect that recursion would be avoided in almost all cases. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Mono XSP & mod_mono support on FreeBSD
Hackers, Currently XSP (Mono's ASP.NET implementation) does not run on FreeBSD. There is a brief post here about the reasons why from David Xu: http://lists.freebsd.org/pipermail/freebsd-threads/2005-March/002944.html Since that message is over 2 years old I hoped that it might no longer be the case, but when I attempted to run the application it does not work. This is the case if you use libc_r, libthr or libpthread. I was using 6.2-STABLE, if it matters. I am interested if anyone knows if this is likely to ever work. I am more than happy to test patches for anyone who wanted to have a go at it. It seems that there was a previous effort to get it ported but that seems to have run to this issue and stopped. I must be in a very small minority who actually wants capability? Thanks, Dominic ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Mono XSP & mod_mono support on FreeBSD
On Sat, 28 Apr 2007, Dominic Marks wrote: Hackers, Currently XSP (Mono's ASP.NET implementation) does not run on FreeBSD. There is a brief post here about the reasons why from David Xu: http://lists.freebsd.org/pipermail/freebsd-threads/2005-March/002944.html Since that message is over 2 years old I hoped that it might no longer be the case, but when I attempted to run the application it does not work. This is the case if you use libc_r, libthr or libpthread. I was using 6.2-STABLE, if it matters. I am interested if anyone knows if this is likely to ever work. I am more than happy to test patches for anyone who wanted to have a go at it. It seems that there was a previous effort to get it ported but that seems to have run to this issue and stopped. Process shared mutexes and condition variables will never be supported in 6.x. They may occur at some point in 7.x. mono should be fixed so that it respects _POSIX_THREAD_PROCESS_SHARED. -- DE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
