On Sat, Nov 1, 2014 at 1:43 PM, Antti Kantee <[email protected]> wrote: > On 31/10/14 20:59, Justin Cormack wrote: >> I noticed that was giving a "timed sleeps not supported" error, which >> reminded me that pthread support is not in an ideal state. >> >> The posix implementation has a fairly incomplete implementation of lwp >> compared to Xen as it doesnt use the hooks into the scheduler. Now it >> could for the fiber implementation, as we left them available as >> public symbols in librumpuser, but everything is in the wrong place >> really. > > There's support on the lwp-rumpfiber branch in rumprun-posix. I forget > why that wasn't merged. Maybe it was because _lwp.c depends on the > underlying threading and we couldn't quite work out how to best address > what you mention below.
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. > 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. >> There are several options, but essentially the threading part is in >> rumpuser and should be providing interfaces for libpthread to hook >> into, either _lwp_* or the create_thread,exit_thread,schedule >> interfaces (optionally) via somestandardised mechanism I would think. > > Yea, I think "somestandardised mechanism" is needed. There is a > proposal for the mechanism in the current code, though that's more of a > "meh whatever works" instead of "some actual thought went into this". > > (I'll use "rumprun pthread" below just to clarify that I'm not talking > about a pthread that a rump kernel may run on) > > I don't think threading is _part_ of rumpuser. But the rumprun pthread > is very heavily intertwined with rumpuser's idea of threads, as we > discussed some whiles ago. For everyone else: think what happens e.g. > when a rumprun pthread calls rump_sys_select() -- if the select call > needs to block, rumpuser needs to know how to do it. Yes, its not entirely part, but hard to separate. But there is a choice of interfaces that can be designed. > This subject needs some concept doodles before it can be fully > understood and best implemented. > > What is clear, at least to me, is that libpthread hooks into _lwp*, > _lwp* hooks into the scheduler, and rumpuser hooks into the scheduler in > a different way. > > It may be that we'd want to provide threading/scheduling as a separate > module. Not sure. I hate having too many modules and fancy > abstractions. But I hate copypasting and merging too. Not sure it can be that separate, as it needs a formal interface. Justin ------------------------------------------------------------------------------ _______________________________________________ rumpkernel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
