On 02/11/14 21:31, Justin Cormack wrote:
> ok as a short term measure I have added a "fiber" option to
> rumprun-posix, but its not 100% useful, as it is not currently working
> with the rumpremote model, but anyway it selects the right _lwp file
> for the threading model. So at least that code is there.

Nice!  (and now we have more options ;) ;)

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)

>> The Xen _lwp.c could benefit from some easy update-by-copypaste if
>> there's an immediate need.  baremetal could also benefit.  It's becoming
>> less and less clear to me why we have completely separate by mostly
>> copypasted platform-level repos for posix, Xen and baremetal.
>
> I think merging the rumpfiber, xen and baremetal implementations is
> probably a good start - will take a look at it. Basically will look at
> adding the assembly implementation of stack switching as an option,
> which is the main difference.

Merging _lwp.c?  Where are you going to host the unified implementation?

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.


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".

------------------------------------------------------------------------------
_______________________________________________
rumpkernel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rumpkernel-users

Reply via email to