On 03/11/14 10:01, Justin Cormack wrote: >> What's stopping it from working with remote syscalls? Is there anything >> besides the kernel server using pthread calls to provision syscalls onto >> workers? (trying to get a sense of the magnitude of the issue) > > Well the server should not matter, you should just be able to use a > non-fiber server... I can't see any reason to ever support a non > pthreads server side, so maybe it would make sense to split out a > librumpserver with the rumpuser_sp stuff in it? Although maybe it > wuold need a pthread librumpuser anyway?
Ah, you want fibers on the client side, I was thinking about the kernel side. > On the client side, the client uses pthreads which might be an issue > (allegedly there are some setcontext/tls issues in netbsd) - not clear > to me if it could be rewritten not to use threads without further > examination. Or why it doesnt try to work anyway - I didnt try very > hard, will look again. The whole sysproxy clientside (i.e. librumpclient) does not use threading. You can link it against libpthread or not link it against libpthread (well, on NetBSD anyway, where libc contains weak stubs for locking routines). I very specifically wrote it to not depend on threading. >> At least Xen and baremetal context switch routines are the same, except >> the latter is less creative with pointers. You could just define a >> whateverprefix_thread_switch(void'ish *prevtcb, void'ish *nexttcb). >> It's difficult to imagine what else would be needed. > > Well I want to support the assembly versions in userspace for > platforms that dont have setcontext, so I wasnt going to do it quite > like that... What's the problem with doing it like that? The assembly versions in Xen and baremetal work fine that way. >> In uncensored idea-land: does it make sense to run the rumprun stack >> directly on top of libpthread? Or do we want a kvm-esque world where a >> native thread (e.g. pthread) is just the unit of potential parallelism >> and fibers are used on top of n native threads? That approach would >> make things always work the same way regardless of if native threads are >> used to achieve parallel execution or not. If the platform does not >> have native threads, could just use 1 native "thread". > > m-n threading is a pain, best avoided, if you want parallelism just > use some sort of native thread exclusively. Plus there are some good > reasons to avoid pthreads that I am working on. Yes, m:n threading is pain, but the above suggestion is not m:n threading no more than fibers are m:n threading (and I'd argue they aren't). I'm not convinced it's a bad approach just because some superficially similar-looking approach was too complex to be done right. I'm not convinced it's a good approach either. Let's just say that your argument didn't change my conviction in either direction ;) So let's assume we want to avoid pthreads but have parallel execution. Is there anything else that can provide native threads without having to write and maintain a separate implementation for every OS (_lwp_create(), rfork(), __clone(), etc.)? ------------------------------------------------------------------------------ _______________________________________________ rumpkernel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
