On Mon, Nov 3, 2014 at 10:46 AM, Antti Kantee <[email protected]> wrote: > 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.
Ok, well should be workable then, will see what is not working... >>> 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. There are some minor differences in initialization to tidy up to make them exactly the same, from memory. Should be pretty simple to converge them though. >>> 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.)? No, not at present. C11 threads is a bit simpler, but is currently only available on Musl, although there might be a C11-on-pthread implementation somewhere. Not aware of any other options. Justin ------------------------------------------------------------------------------ _______________________________________________ rumpkernel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
