On Sun, Jan 25, 2015 at 3:39 PM, Norman Feske <[email protected]> wrote: > Does that mean that Rump kernels do not rely on preemptive threading? If > yes, user-level thread scheduling (e.g., based on setjmp, longjmp) would > do? What keeps you back from doing this by default? This would make Rump > kernel behave deterministically across all host platforms and possibly > simplify the hypercall interface. Wouldn't that be desirable?
Indeed there is no requirement for preemptive threading. There is a userlevel scheduling implementation already, using swapcontext, which is upstream in NetBSD as an option, see https://github.com/rumpkernel/wiki/wiki/Platforms%3A-Userspace-fibers It is more-or-less the same version as Xen and baremetal use; at some point it will be exactly the same. There are various reasons it is not the default implementation 1. The swapcontext calls are not in Posix, I am working assember replacement 2. As Antti said in this thread, it is generally the case that you want to use the same threading model as you are using for userspace threads, so having multiple implementations is useful. 3. pthreads does provide real concurrency 4. Some of the other supporting code (tests, some example block drivers etc) does assume concurrency. But the determinism is certainly useful, as are other properties, so both will be maintained. Justin ------------------------------------------------------------------------------ New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet _______________________________________________ rumpkernel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
