ANN: Lua OS 0.4
Locked
12
12
ANN: Lua OS 0.4
 
|
Attention, People of the Moon!
Lua OS 0.4 is here! Looots of progress!! And this time, it runs on Windows. New features in 0.4: A unified application running the Java frontend + the Lua backend Full system hibernation (this is still experimental and quite certainly buggy) More info & download here: http://LuaOS.net/luaos-0.4.php Oh, and BTW: Actual preemptive multitasking is underway. I've seen it work, but there's some issues to take care of as per usual in these bitchy multithreaded projects. Thus, threads are not yet enabled in this version. In Lua OS 0.4 everything's cooperative (coroutines). Implementing everything is much simpler that way, and we don't really lose anything in terms of power of the platform. Preemptive multitasking is more like an optimization than an actual feature. Since we have protection against endless loops anyway :D Cheers - Stefan |
Re: ANN: Lua OS 0.4
|
Might you consider a concurrency model that isn't the classic threads+locks?
On 16 August 2011 05:25, Stefan Reich <[hidden email]> wrote: Attention, People of the Moon! "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. |
Re: ANN: Lua OS 0.4
|
|
There are no locks in Lua OS. My model also not threading in the
classical sense (different threads working on the same data - the model that leads to the well-known problems). I once held a talk about the evils of multithreading, so I very clearly am sure to avoid that. The model is basically: event loops (on the sandbox level) plus communicating processes (on the next-higher level). Thus there is never any concurrent action on the same data. Each strain of execution has its own data. All communication is by message passing. Does that satisfy your question...? Cheers, Stefan On Tue, Aug 16, 2011 at 8:20 AM, Michael Richter <[hidden email]> wrote: > Might you consider a concurrency model that isn't the classic threads+locks? > > On 16 August 2011 05:25, Stefan Reich > <[hidden email]> wrote: >> >> Attention, People of the Moon! >> >> Lua OS 0.4 is here! Looots of progress!! And this time, it runs on >> Windows. >> >> New features in 0.4: >> >> A unified application running the Java frontend + the Lua backend >> Full system hibernation (this is still experimental and quite >> certainly buggy) >> >> More info & download here: http://LuaOS.net/luaos-0.4.php >> >> Oh, and BTW: Actual preemptive multitasking is underway. I've seen it >> work, but there's some issues to take care of as per usual in these >> bitchy multithreaded projects. >> >> Thus, threads are not yet enabled in this version. In Lua OS 0.4 >> everything's cooperative (coroutines). Implementing everything is much >> simpler that way, and we don't really lose anything in terms of power >> of the platform. Preemptive multitasking is more like an optimization >> than an actual feature. Since we have protection against endless loops >> anyway :D >> >> Cheers - >> Stefan >> > > > > -- > "Perhaps people don't believe this, but throughout all of the discussions of > entering China our focus has really been what's best for the Chinese people. > It's not been about our revenue or profit or whatnot." > --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. > |
Re: ANN: Lua OS 0.4
|
> There are no locks in Lua OS. My model also not threading in the
> classical sense (different threads working on the same data - the > model that leads to the well-known problems). I once held a talk about > the evils of multithreading, so I very clearly am sure to avoid that. > > The model is basically: event loops (on the sandbox level) plus > communicating processes (on the next-higher level). > > Thus there is never any concurrent action on the same data. Each > strain of execution has its own data. All communication is by message > passing. Great! -- Roberto |
Re: ANN: Lua OS 0.4
|
In reply to this post by Stefan Reich
Sounds interesting. What type of message passing architecture is in place? Possibly a tagged format like what was used by BeOS? I found that particular format very flexible/adaptable.
Flexible enough that I have used MUSCLE (https://public.msli.com/lcs/muscle/index.html) messages (which emulate the BeOS Messages) as the basis of the message architecture used in all my multi-threaded code in the last 7 years or so. Just a thought. Terry On Tue, Aug 16, 2011 at 05:57, Stefan Reich <[hidden email]> wrote: There are no locks in Lua OS. My model also not threading in the |
Re: ANN: Lua OS 0.4
|
|
Jo... I just made a reference manual for Lua OS 0.4 that might answer
these questions: http://luaos.net/docs/safelua-api.html I am going for a very simple message format here. Each message has a recipient, a command (string) and some data (a Lua table without anything irregular like functions, userdata or recursion). This should allow you to do whatever you want... :o) Stefan PS: BeOS was nice (I totally loved it back in the day), but it's probably a completely different beast as it's C++-based (if I remember correctly) and not script-centric. We really have something new here: a completely script language-based OS is a whole new thing in terms of how you program for the system. On Tue, Aug 16, 2011 at 3:15 PM, Terry Bayne <[hidden email]> wrote: > Sounds interesting. What type of message passing architecture is in place? > Possibly a tagged format like what was used by BeOS? I found that > particular format very flexible/adaptable. > > Flexible enough that I have used MUSCLE > (https://public.msli.com/lcs/muscle/index.html) messages (which emulate the > BeOS Messages) as the basis of the message architecture used in all my > multi-threaded code in the last 7 years or so. > > Just a thought. > > Terry > > On Tue, Aug 16, 2011 at 05:57, Stefan Reich > <[hidden email]> wrote: >> >> There are no locks in Lua OS. My model also not threading in the >> classical sense (different threads working on the same data - the >> model that leads to the well-known problems). I once held a talk about >> the evils of multithreading, so I very clearly am sure to avoid that. >> >> The model is basically: event loops (on the sandbox level) plus >> communicating processes (on the next-higher level). >> >> Thus there is never any concurrent action on the same data. Each >> strain of execution has its own data. All communication is by message >> passing. >> >> Does that satisfy your question...? >> >> Cheers, >> Stefan >> >> On Tue, Aug 16, 2011 at 8:20 AM, Michael Richter <[hidden email]> >> wrote: >> > Might you consider a concurrency model that isn't the classic >> > threads+locks? >> > >> > On 16 August 2011 05:25, Stefan Reich >> > <[hidden email]> wrote: >> >> >> >> Attention, People of the Moon! >> >> >> >> Lua OS 0.4 is here! Looots of progress!! And this time, it runs on >> >> Windows. >> >> >> >> New features in 0.4: >> >> >> >> A unified application running the Java frontend + the Lua backend >> >> Full system hibernation (this is still experimental and quite >> >> certainly buggy) >> >> >> >> More info & download here: http://LuaOS.net/luaos-0.4.php >> >> >> >> Oh, and BTW: Actual preemptive multitasking is underway. I've seen it >> >> work, but there's some issues to take care of as per usual in these >> >> bitchy multithreaded projects. >> >> >> >> Thus, threads are not yet enabled in this version. In Lua OS 0.4 >> >> everything's cooperative (coroutines). Implementing everything is much >> >> simpler that way, and we don't really lose anything in terms of power >> >> of the platform. Preemptive multitasking is more like an optimization >> >> than an actual feature. Since we have protection against endless loops >> >> anyway :D >> >> >> >> Cheers - >> >> Stefan >> >> >> > >> > >> > >> > -- >> > "Perhaps people don't believe this, but throughout all of the >> > discussions of >> > entering China our focus has really been what's best for the Chinese >> > people. >> > It's not been about our revenue or profit or whatnot." >> > --Sergey Brin, demonstrating the emptiness of the "don't be evil" >> > mantra. >> > >> > > |
Re: ANN: Lua OS 0.4
|
|
In reply to this post by Roberto Ierusalimschy
Oi...! The Lua master approves of my concept? Niiice =)
Stefan On Tue, Aug 16, 2011 at 2:46 PM, Roberto Ierusalimschy <[hidden email]> wrote: >> Thus there is never any concurrent action on the same data. Each >> strain of execution has its own data. All communication is by message >> passing. > > Great! > > -- Roberto > > |
Re: ANN: Lua OS 0.4
|
|
In reply to this post by Stefan Reich
It does indeed! -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. |
Re: ANN: Lua OS 0.4
|
In reply to this post by Stefan Reich
Hi Stefan,
As far as I can understand from your reference manual, all sandboxes in one "cage" share one Lua VM. Is it safe to use multiple sandboxes with different "powers" inside one VM? I guess you set a separate environment for each thread, but anyway. Second, I've read in the manual that it's possible to set a timeout for a sandbox. This is really necessary, but shutting down the process which exceeded the timeout doesn't seem a good idea to me. I guess you limit the number of instructions via the debug hook. So is it possible to call lua_yeild from the debug hook instead of terminating the sandbox? This could be compared to the timer interrupt. In future, this could provide a way to implement sort of preemptive multithreading. Yes, things get complicated here since you'll need to implement a scheduler. -- Gregory |
Re: ANN: Lua OS 0.4
|
I just visited luaos.net and wanted to inquire about Java being listed
as a dependency. Is the Java userspace app being used to temporarily bootstrap your project, serving as a laboratory, or as part of the long term infrastructure? Is the eventual goal of a "Lua OS" to use Lua to write operating system facilities for managing processes and daemons written in language X, or to write a program in language X for managing processes and daemons written in Lua? The advantages to writing an OS in Lua would primarily be security and agility. By security I mean moving as much OS string handling as possible from the "raw blocks of RAM" char * approach to Lua strings. String handling is simply done correctly once in the Lua implementation, there is no debate over 'sprintf' etc. appearing in the OS code base. By agility I mean fewer lines of code, no (infrequent) recompiling of the OS, quicker refactoring, and increased customization. A secondary advantage would be to provide a convenient development environment for programming in Lua. UNIX at its core is a development and runtime environment for C programs. One gradual, evolutionary approach for generating a Lua OS would be to start it as a fork of a minimal Linux distro, such as Arch Linux[1], with the Lua windowing manager Awesome[2]. This way you immediately start with a modern, working desktop configurable with Lua, that can be distributed to as many Lua developers as possible. Then, with this distribution under source control, users\developers start gradually cannablizing C infrastructure, replacing it with Lua or calls to the LuaJIT ffi. This process would eventually go down to the Kernel. Important "glue" would be replaced, but everything deemed low priority would be left as-is, such as hardware drivers. Perhaps you would end up with something analagous to PUC-Rio Lua, a small core for pushing new Lua (OS) states and pushing\popping (hardware) calls. Another approach would be to go completely bottom up from the hardware level, but I'd predict one would have a very hard time recruiting driver developers\testers to ensure portability, unless the project already had value to offer. A chicken-and-egg scenario. Just throwing out some ideas. An "operating system" is necessarily very broad in scope. I'm not sure if the three benefits I could think of a "Lua operating system" providing (security, agility, development environment) intersect with your thoughts on the subject. -David Hollander [1] https://wiki.archlinux.org/index.php/Arch_Linux [2] http://awesome.naquadah.org/ On Wed, Aug 17, 2011 at 2:01 AM, Gregory Bonik <[hidden email]> wrote: > Hi Stefan, > > As far as I can understand from your reference manual, all sandboxes in > one "cage" share one Lua VM. Is it safe to use multiple sandboxes with > different "powers" inside one VM? I guess you set a separate environment > for each thread, but anyway. > > Second, I've read in the manual that it's possible to set a timeout for > a sandbox. This is really necessary, but shutting down the process which > exceeded the timeout doesn't seem a good idea to me. I guess you limit > the number of instructions via the debug hook. So is it possible to call > lua_yeild from the debug hook instead of terminating the sandbox? This > could be compared to the timer interrupt. In future, this could provide > a way to implement sort of preemptive multithreading. Yes, things get > complicated here since you'll need to implement a scheduler. > > -- Gregory > > > > |
Re: ANN: Lua OS 0.4
|
On Wed, 17 Aug 2011 15:05:17 -0500, David Hollander wrote:
> One gradual, evolutionary approach for generating a Lua OS would be > to > start it as a fork of a minimal Linux distro, such as Arch Linux[1], > with the Lua windowing manager Awesome[2]. This is kind of OT since I don't think what you propose aligns with the plans of the OP, but Awesome is no longer maintained and its author has moved away from Lua personally. It would be nice to see someone continue to work on it though! -- Pierre 'catwell' Chapuis |
Re: ANN: Lua OS 0.4
|
In reply to this post by Roberto Ierusalimschy
On Tue, Aug 16, 2011 at 2:46 PM, Roberto Ierusalimschy <[hidden email]> wrote:
This is exactly what LuaAV and Lubyk do (no concurrent execution on the Lua state). It is the second time I hear praise of the coroutine based model and I do not see why using a Lua scheduler/event loop is any better or even different from using the OS for scheduling through the use of a mutex: A. coroutine model (LuaAV, Lua OS) 1. needs an explicit event/scheduling loop in Lua 2. needs an inbox 3. needs a mutex on the inbox to get/post messages from external processes
B. mutex model (Lubyk) 1. needs a mutex to enter the Lua state 2. needs to release mutex while idle in C space (receiving from socket/zmq/os callback) Both models imply the use of a mutex per Lua state (for the inbox or the whole state) but from my understanding model "B" is more powerful because: 1. it let's you implement model "A" without changing any of the C API (just post a message in an inbox instead of running the code).
2. it can cope with os callbacks that cannot transfer execution to another thread (OpenGL). Are there any reasons why people choose the coroutine approach apart from "mutex" sounding like a swearword and "coroutine" like pillow talk ?
Gaspard |
Re: ANN: Lua OS 0.4
|
On Thu, Aug 18, 2011 at 10:48 AM, Gaspard Bucher <[hidden email]> wrote:
> 2. it can cope with os callbacks that cannot transfer execution to another > thread (OpenGL). This is the model I followed with Winapi, where it's also important to ensure that callbacks happen on the GUI thread. (This requires a peculiarly Windows hack, using a message queue on a window to transfer stuff to the GUI thread) OK, the downside is that you can only do one thing at a time, but then coroutines can be used on top of this to maintain the illusion of concurrency. steve d. |
Re: ANN: Lua OS 0.4
|
|
In reply to this post by Gregory Bonik
Hi Gregory!
On Wed, Aug 17, 2011 at 9:01 AM, Gregory Bonik <[hidden email]> wrote: > Hi Stefan, > > As far as I can understand from your reference manual, all sandboxes in > one "cage" share one Lua VM. Is it safe to use multiple sandboxes with > different "powers" inside one VM? I guess you set a separate environment > for each thread, but anyway. Yes, the powers are set per sandbox. "Empowered" sandboxes can coexist with "powerless" sandboxes in one cage. > Second, I've read in the manual that it's possible to set a timeout for > a sandbox. This is really necessary, but shutting down the process which > exceeded the timeout doesn't seem a good idea to me. I guess you limit > the number of instructions via the debug hook. So is it possible to call > lua_yeild from the debug hook instead of terminating the sandbox? Yes, I thought about that too. You could call it "forced yields". The thing is, I am not sure if that works. The problematic case is when the thread is in the middle of a sensitive operation when the debug hook hits. Specifically, when an OS function is being executed. We don't want to yield then since it would screw up the integrity of OS data structures. So we'd need a lock to prevent yielding at the wrong moment. Furthermore, there are callbacks from OS to user code. Message and persistence handlers are called by the OS at arbitrary times. With cooperative multitasking, user code decides when it is ready to accept such calls. With forced yields, it could happen at any time. I don't really think we should go down that route for now... we have preemptive multithreading on another level. But someone could do a liittle experiment on forced yields and see if they're feasible. > Yes, things get > complicated here since you'll need to implement a scheduler. Yeah well, we'll need a cooperative scheduler anyway. Round-robin is nice, but it would be even smarter to have a more flexible approach. Stefan |
Re: ANN: Lua OS 0.4
|
|
Stefan Reich wrote:
> The problematic case is when the thread is in the middle of a > sensitive operation when the debug hook hits. Specifically, when an OS > function is being executed. We don't want to yield then since it would > screw up the integrity of OS data structures. I beleive it's not true. Debug hook is called only when the execution is in the Lua VM, i.e. it cannot be called while the C code is running. Anyway, I bet you call lua_error from the debug hook to stop the sandbox which exceeded the time limit -- why don't you worry about data integrity then? Technically, it's almost the same. We should, however, find out whether calling lua_yield from a debug hook is legal. Lua 5.1 documentation of coroutine.yeild says the following: "The coroutine cannot be running a C function, a metamethod, or an iterator." But the 5.2 reference manual doesn't have such wording. It is interesting whether this limitation really no longer exists or this is a mistake in the manual. > Furthermore, there are callbacks from OS to user code. By the way, how and when do you call these callbacks? Do you pass them as arguments to resume() and execute right after yield() returns? I.e. like that: local events = coroutine.yield() for i, e in ipairs(events) do e() end > Message and > persistence handlers are called by the OS at arbitrary times. With > cooperative multitasking, user code decides when it is ready to accept > such calls. With forced yields, it could happen at any time. You could mark a sandbox which was forced to yield with a flag. When you resume a sandbox with such flag, just don't pass events to it and remove the flag. |
Re: ANN: Lua OS 0.4
|
|
Gregory:
On Thu, Aug 18, 2011 at 5:21 PM, Gregory Bonik <[hidden email]> wrote: > Stefan Reich wrote: >> The problematic case is when the thread is in the middle of a >> sensitive operation when the debug hook hits. Specifically, when an OS >> function is being executed. We don't want to yield then since it would >> screw up the integrity of OS data structures. > > I beleive it's not true. Debug hook is called only when the execution is > in the Lua VM, i.e. it cannot be called while the C code is running. Well in Lua OS, OS code is Lua code too :) No custom C code planned at this point. > Anyway, I bet you call lua_error from the debug hook to stop the sandbox > which exceeded the time limit -- why don't you worry about data > integrity then? Technically, it's almost the same. Oops. You're actually right. So we should have a "we're in OS code" flag anyway. > We should, however, find out whether calling lua_yield from a debug hook > is legal. Lua 5.1 documentation of coroutine.yeild says the following: > "The coroutine cannot be running a C function, a metamethod, > or an iterator." > But the 5.2 reference manual doesn't have such wording. It is > interesting whether this limitation really no longer exists or this is a > mistake in the manual. Are we doing any of that? I believe we're not... >> Furthermore, there are callbacks from OS to user code. > By the way, how and when do you call these callbacks? Do you pass them > as arguments to resume() and execute right after yield() returns? I.e. > like that: > > local events = coroutine.yield() > for i, e in ipairs(events) do e() end Yes, it's like that actually. Although the events could also just be put in a variable somewhere. > You could mark a sandbox which was forced to yield with a flag. When you > resume a sandbox with such flag, just don't pass events to it and remove > the flag. Yes, that could work... so we'd have a sandbox that might be unresponsive to events, but never blocking the whole cage. You're making some really good points I must say. I might actually implement this and see if it can be done... :) -Stefan |
Re: ANN: Lua OS 0.4
|
|
In reply to this post by David Hollander
Yeah, good question.. why would a Lua OS need a Java part? Here's what
the Java app currently does: -launches lua.exe with appropriate options and shows its output in a window -connects to the Lua process via socket -displays a GUI for the Lua OS task manager (the backend of which is of course written in Lua) -functions as a GUI server for Lua OS processes (this will probably be demonstrated in Lua OS 0.5) I wasn't too happy with all the Lua GUI toolkit bindings I tried (too complicated to learn, too strange, too buggy...), so I went for a trusted platform which is Java (Swing). It really works fine, I think I'll be showing some actual GUI apps soon. Whether Java will remain in the long-term instrastructure is an open question. People could decide to use the Lua+Java combo - or write a frontend in another language. > Is the eventual goal of a "Lua OS" to use Lua to write operating > system facilities for managing processes and daemons written in > language X, > or to write a program in language X for managing processes and daemons > written in Lua? The goal is to have processes and daemons written in Lua. I don't plan on including support for apps written in any other languages in the OS. This could definitely be added later, but then you might lose the advantages of a Lua OS which depend on all code being in Lua. It's an open question anyway. I think JavaOS and JOS were supposed to run Java code only, too... > One gradual, evolutionary approach for generating a Lua OS would be to > start it as a fork of a minimal Linux distro, such as Arch Linux[1], > with the Lua windowing manager Awesome[2]. Yeah, we're basically doing that. I don't want to write a kernel, so we use a standard Linux kernel (or even WIndows). On top of that we put the Lua interpreter and some GUI (e.g. Java). What Linux distro is used is up to anyone's preference. I have chosen Ubuntu for now because it was the only distro that worked properly for me in VirtualBox =) Stefan On Wed, Aug 17, 2011 at 10:05 PM, David Hollander <[hidden email]> wrote: > I just visited luaos.net and wanted to inquire about Java being listed > as a dependency. Is the Java userspace app being used to temporarily > bootstrap your project, serving as a laboratory, or as part of the > long term infrastructure? > > Is the eventual goal of a "Lua OS" to use Lua to write operating > system facilities for managing processes and daemons written in > language X, > or to write a program in language X for managing processes and daemons > written in Lua? > > The advantages to writing an OS in Lua would primarily be security and > agility. By security I mean moving as much OS string handling as > possible from the "raw blocks of RAM" char * approach to Lua strings. > String handling is simply done correctly once in the Lua > implementation, there is no debate over 'sprintf' etc. appearing in > the OS code base. By agility I mean fewer lines of code, no > (infrequent) recompiling of the OS, quicker refactoring, and increased > customization. A secondary advantage would be to provide a convenient > development environment for programming in Lua. UNIX at its core is a > development and runtime environment for C programs. > > One gradual, evolutionary approach for generating a Lua OS would be to > start it as a fork of a minimal Linux distro, such as Arch Linux[1], > with the Lua windowing manager Awesome[2]. This way you immediately > start with a modern, working desktop configurable with Lua, that can > be distributed to as many Lua developers as possible. Then, with this > distribution under source control, users\developers start gradually > cannablizing C infrastructure, replacing it with Lua or calls to the > LuaJIT ffi. This process would eventually go down to the Kernel. > Important "glue" would be replaced, but everything deemed low priority > would be left as-is, such as hardware drivers. Perhaps you would end > up with something analagous to PUC-Rio Lua, a small core for pushing > new Lua (OS) states and pushing\popping (hardware) calls. > > Another approach would be to go completely bottom up from the hardware > level, but I'd predict one would have a very hard time recruiting > driver developers\testers to ensure portability, unless the project > already had value to offer. A chicken-and-egg scenario. > > Just throwing out some ideas. An "operating system" is necessarily > very broad in scope. I'm not sure if the three benefits I could think > of a "Lua operating system" providing (security, agility, development > environment) intersect with your thoughts on the subject. > > -David Hollander > > [1] https://wiki.archlinux.org/index.php/Arch_Linux > [2] http://awesome.naquadah.org/ > > > > On Wed, Aug 17, 2011 at 2:01 AM, Gregory Bonik <[hidden email]> wrote: >> Hi Stefan, >> >> As far as I can understand from your reference manual, all sandboxes in >> one "cage" share one Lua VM. Is it safe to use multiple sandboxes with >> different "powers" inside one VM? I guess you set a separate environment >> for each thread, but anyway. >> >> Second, I've read in the manual that it's possible to set a timeout for >> a sandbox. This is really necessary, but shutting down the process which >> exceeded the timeout doesn't seem a good idea to me. I guess you limit >> the number of instructions via the debug hook. So is it possible to call >> lua_yeild from the debug hook instead of terminating the sandbox? This >> could be compared to the timer interrupt. In future, this could provide >> a way to implement sort of preemptive multithreading. Yes, things get >> complicated here since you'll need to implement a scheduler. >> >> -- Gregory >> >> >> >> > > |
Re: ANN: Lua OS 0.4
|
|
This plan sounds like COPAS so far, not sure if I would call an event
loop for one concurrency method for one programming language an OS. What are the advantages to scheduling runtime for Lua scripts inside of a single Lua process with the additional overhead of coroutines, versus just launching multiple Lua processes normally and letting the OS schedule them? This sounds like a bit of an abstract and slower workaround for the lack of a Lua daemon module, perhaps the one from Python could be ported. On 8/18/11, Stefan Reich <[hidden email]> wrote: > Yeah, good question.. why would a Lua OS need a Java part? Here's what > the Java app currently does: > > -launches lua.exe with appropriate options and shows its output in a window > -connects to the Lua process via socket > -displays a GUI for the Lua OS task manager (the backend of which is > of course written in Lua) > -functions as a GUI server for Lua OS processes (this will probably be > demonstrated in Lua OS 0.5) > > I wasn't too happy with all the Lua GUI toolkit bindings I tried (too > complicated to learn, too strange, too buggy...), so I went for a > trusted platform which is Java (Swing). It really works fine, I think > I'll be showing some actual GUI apps soon. > > Whether Java will remain in the long-term instrastructure is an open > question. People could decide to use the Lua+Java combo - or write a > frontend in another language. > >> Is the eventual goal of a "Lua OS" to use Lua to write operating >> system facilities for managing processes and daemons written in >> language X, >> or to write a program in language X for managing processes and daemons >> written in Lua? > > The goal is to have processes and daemons written in Lua. I don't plan > on including support for apps written in any other languages in the > OS. This could definitely be added later, but then you might lose the > advantages of a Lua OS which depend on all code being in Lua. It's an > open question anyway. > > I think JavaOS and JOS were supposed to run Java code only, too... > >> One gradual, evolutionary approach for generating a Lua OS would be to >> start it as a fork of a minimal Linux distro, such as Arch Linux[1], >> with the Lua windowing manager Awesome[2]. > > Yeah, we're basically doing that. I don't want to write a kernel, so > we use a standard Linux kernel (or even WIndows). On top of that we > put the Lua interpreter and some GUI (e.g. Java). > > What Linux distro is used is up to anyone's preference. I have chosen > Ubuntu for now because it was the only distro that worked properly for > me in VirtualBox =) > > Stefan > > On Wed, Aug 17, 2011 at 10:05 PM, David Hollander <[hidden email]> wrote: >> I just visited luaos.net and wanted to inquire about Java being listed >> as a dependency. Is the Java userspace app being used to temporarily >> bootstrap your project, serving as a laboratory, or as part of the >> long term infrastructure? >> >> Is the eventual goal of a "Lua OS" to use Lua to write operating >> system facilities for managing processes and daemons written in >> language X, >> or to write a program in language X for managing processes and daemons >> written in Lua? >> >> The advantages to writing an OS in Lua would primarily be security and >> agility. By security I mean moving as much OS string handling as >> possible from the "raw blocks of RAM" char * approach to Lua strings. >> String handling is simply done correctly once in the Lua >> implementation, there is no debate over 'sprintf' etc. appearing in >> the OS code base. By agility I mean fewer lines of code, no >> (infrequent) recompiling of the OS, quicker refactoring, and increased >> customization. A secondary advantage would be to provide a convenient >> development environment for programming in Lua. UNIX at its core is a >> development and runtime environment for C programs. >> >> One gradual, evolutionary approach for generating a Lua OS would be to >> start it as a fork of a minimal Linux distro, such as Arch Linux[1], >> with the Lua windowing manager Awesome[2]. This way you immediately >> start with a modern, working desktop configurable with Lua, that can >> be distributed to as many Lua developers as possible. Then, with this >> distribution under source control, users\developers start gradually >> cannablizing C infrastructure, replacing it with Lua or calls to the >> LuaJIT ffi. This process would eventually go down to the Kernel. >> Important "glue" would be replaced, but everything deemed low priority >> would be left as-is, such as hardware drivers. Perhaps you would end >> up with something analagous to PUC-Rio Lua, a small core for pushing >> new Lua (OS) states and pushing\popping (hardware) calls. >> >> Another approach would be to go completely bottom up from the hardware >> level, but I'd predict one would have a very hard time recruiting >> driver developers\testers to ensure portability, unless the project >> already had value to offer. A chicken-and-egg scenario. >> >> Just throwing out some ideas. An "operating system" is necessarily >> very broad in scope. I'm not sure if the three benefits I could think >> of a "Lua operating system" providing (security, agility, development >> environment) intersect with your thoughts on the subject. >> >> -David Hollander >> >> [1] https://wiki.archlinux.org/index.php/Arch_Linux >> [2] http://awesome.naquadah.org/ >> >> >> >> On Wed, Aug 17, 2011 at 2:01 AM, Gregory Bonik <[hidden email]> wrote: >>> Hi Stefan, >>> >>> As far as I can understand from your reference manual, all sandboxes in >>> one "cage" share one Lua VM. Is it safe to use multiple sandboxes with >>> different "powers" inside one VM? I guess you set a separate environment >>> for each thread, but anyway. >>> >>> Second, I've read in the manual that it's possible to set a timeout for >>> a sandbox. This is really necessary, but shutting down the process which >>> exceeded the timeout doesn't seem a good idea to me. I guess you limit >>> the number of instructions via the debug hook. So is it possible to call >>> lua_yeild from the debug hook instead of terminating the sandbox? This >>> could be compared to the timer interrupt. In future, this could provide >>> a way to implement sort of preemptive multithreading. Yes, things get >>> complicated here since you'll need to implement a scheduler. >>> >>> -- Gregory >>> >>> >>> >>> >> >> > > |
|
In reply to this post by Stefan Reich
On Thu, Aug 18, 2011 at 07:41, Stefan Reich
<[hidden email]> wrote: > Hi Gregory! > > On Wed, Aug 17, 2011 at 9:01 AM, Gregory Bonik <[hidden email]> wrote: >> Hi Stefan, >> >> As far as I can understand from your reference manual, all sandboxes in >> one "cage" share one Lua VM. Is it safe to use multiple sandboxes with >> different "powers" inside one VM? I guess you set a separate environment >> for each thread, but anyway. > > Yes, the powers are set per sandbox. "Empowered" sandboxes can coexist > with "powerless" sandboxes in one cage. > >> Second, I've read in the manual that it's possible to set a timeout for >> a sandbox. This is really necessary, but shutting down the process which >> exceeded the timeout doesn't seem a good idea to me. I guess you limit >> the number of instructions via the debug hook. So is it possible to call >> lua_yeild from the debug hook instead of terminating the sandbox? > > Yes, I thought about that too. You could call it "forced yields". The > thing is, I am not sure if that works. > > The problematic case is when the thread is in the middle of a > sensitive operation when the debug hook hits. Specifically, when an OS > function is being executed. We don't want to yield then since it would > screw up the integrity of OS data structures. So we'd need a lock to > prevent yielding at the wrong moment. > > Furthermore, there are callbacks from OS to user code. Message and > persistence handlers are called by the OS at arbitrary times. With > cooperative multitasking, user code decides when it is ready to accept > such calls. With forced yields, it could happen at any time. > > I don't really think we should go down that route for now... we have > preemptive multithreading on another level. But someone could do a > liittle experiment on forced yields and see if they're feasible. > >> Yes, things get >> complicated here since you'll need to implement a scheduler. > > Yeah well, we'll need a cooperative scheduler anyway. Round-robin is > nice, but it would be even smarter to have a more flexible approach. > > Stefan > > I think the term you want is "critical section". A thread can ask that it not be interrupted until it finishes some task (delimited by calls to EnterCriticalSection and LeaveCriticalSection or similar). Of course then you have to figure out what to do if a thread gets into an endless loop in that section... Long-running C functions are another possible issue. Even if you don't provide any of your own, Lua still has some. e.g. what if a thread does something silly like print(('gdfhfs'):rep(9999999999)) ? -- Sent from my toaster. |
Re: ANN: Lua OS 0.4
|
|
In reply to this post by David Hollander
Uhm... are you kidding or something?
Copas is a dispatcher for TCP servers. Lua OS is a system for sandboxes (which Copas has no notion of) with fine-grained security control (which Copas has no notion of), a GUI (which Copas has no notion of) and, among other things, a hibernation/code mobility concept. Not saying that Copas is a bad thing - it's great -, but it has a completely different focus, and it has nothing to do with the sandboxes that are the crucial concept in Lua OS. On Thu, Aug 18, 2011 at 10:38 PM, David Hollander <[hidden email]> wrote: > This plan sounds like COPAS so far, not sure if I would call an event > loop for one concurrency method for one programming language an OS. > What are the advantages to scheduling runtime for Lua scripts inside > of a single Lua process with the additional overhead of coroutines, > versus just launching multiple Lua processes normally and letting the > OS schedule them? This sounds like a bit of an abstract and slower > workaround for the lack of a Lua daemon module, perhaps the one from > Python could be ported. > > On 8/18/11, Stefan Reich <[hidden email]> wrote: >> Yeah, good question.. why would a Lua OS need a Java part? Here's what >> the Java app currently does: >> >> -launches lua.exe with appropriate options and shows its output in a window >> -connects to the Lua process via socket >> -displays a GUI for the Lua OS task manager (the backend of which is >> of course written in Lua) >> -functions as a GUI server for Lua OS processes (this will probably be >> demonstrated in Lua OS 0.5) >> >> I wasn't too happy with all the Lua GUI toolkit bindings I tried (too >> complicated to learn, too strange, too buggy...), so I went for a >> trusted platform which is Java (Swing). It really works fine, I think >> I'll be showing some actual GUI apps soon. >> >> Whether Java will remain in the long-term instrastructure is an open >> question. People could decide to use the Lua+Java combo - or write a >> frontend in another language. >> >>> Is the eventual goal of a "Lua OS" to use Lua to write operating >>> system facilities for managing processes and daemons written in >>> language X, >>> or to write a program in language X for managing processes and daemons >>> written in Lua? >> >> The goal is to have processes and daemons written in Lua. I don't plan >> on including support for apps written in any other languages in the >> OS. This could definitely be added later, but then you might lose the >> advantages of a Lua OS which depend on all code being in Lua. It's an >> open question anyway. >> >> I think JavaOS and JOS were supposed to run Java code only, too... >> >>> One gradual, evolutionary approach for generating a Lua OS would be to >>> start it as a fork of a minimal Linux distro, such as Arch Linux[1], >>> with the Lua windowing manager Awesome[2]. >> >> Yeah, we're basically doing that. I don't want to write a kernel, so >> we use a standard Linux kernel (or even WIndows). On top of that we >> put the Lua interpreter and some GUI (e.g. Java). >> >> What Linux distro is used is up to anyone's preference. I have chosen >> Ubuntu for now because it was the only distro that worked properly for >> me in VirtualBox =) >> >> Stefan >> >> On Wed, Aug 17, 2011 at 10:05 PM, David Hollander <[hidden email]> wrote: >>> I just visited luaos.net and wanted to inquire about Java being listed >>> as a dependency. Is the Java userspace app being used to temporarily >>> bootstrap your project, serving as a laboratory, or as part of the >>> long term infrastructure? >>> >>> Is the eventual goal of a "Lua OS" to use Lua to write operating >>> system facilities for managing processes and daemons written in >>> language X, >>> or to write a program in language X for managing processes and daemons >>> written in Lua? >>> >>> The advantages to writing an OS in Lua would primarily be security and >>> agility. By security I mean moving as much OS string handling as >>> possible from the "raw blocks of RAM" char * approach to Lua strings. >>> String handling is simply done correctly once in the Lua >>> implementation, there is no debate over 'sprintf' etc. appearing in >>> the OS code base. By agility I mean fewer lines of code, no >>> (infrequent) recompiling of the OS, quicker refactoring, and increased >>> customization. A secondary advantage would be to provide a convenient >>> development environment for programming in Lua. UNIX at its core is a >>> development and runtime environment for C programs. >>> >>> One gradual, evolutionary approach for generating a Lua OS would be to >>> start it as a fork of a minimal Linux distro, such as Arch Linux[1], >>> with the Lua windowing manager Awesome[2]. This way you immediately >>> start with a modern, working desktop configurable with Lua, that can >>> be distributed to as many Lua developers as possible. Then, with this >>> distribution under source control, users\developers start gradually >>> cannablizing C infrastructure, replacing it with Lua or calls to the >>> LuaJIT ffi. This process would eventually go down to the Kernel. >>> Important "glue" would be replaced, but everything deemed low priority >>> would be left as-is, such as hardware drivers. Perhaps you would end >>> up with something analagous to PUC-Rio Lua, a small core for pushing >>> new Lua (OS) states and pushing\popping (hardware) calls. >>> >>> Another approach would be to go completely bottom up from the hardware >>> level, but I'd predict one would have a very hard time recruiting >>> driver developers\testers to ensure portability, unless the project >>> already had value to offer. A chicken-and-egg scenario. >>> >>> Just throwing out some ideas. An "operating system" is necessarily >>> very broad in scope. I'm not sure if the three benefits I could think >>> of a "Lua operating system" providing (security, agility, development >>> environment) intersect with your thoughts on the subject. >>> >>> -David Hollander >>> >>> [1] https://wiki.archlinux.org/index.php/Arch_Linux >>> [2] http://awesome.naquadah.org/ >>> >>> >>> >>> On Wed, Aug 17, 2011 at 2:01 AM, Gregory Bonik <[hidden email]> wrote: >>>> Hi Stefan, >>>> >>>> As far as I can understand from your reference manual, all sandboxes in >>>> one "cage" share one Lua VM. Is it safe to use multiple sandboxes with >>>> different "powers" inside one VM? I guess you set a separate environment >>>> for each thread, but anyway. >>>> >>>> Second, I've read in the manual that it's possible to set a timeout for >>>> a sandbox. This is really necessary, but shutting down the process which >>>> exceeded the timeout doesn't seem a good idea to me. I guess you limit >>>> the number of instructions via the debug hook. So is it possible to call >>>> lua_yeild from the debug hook instead of terminating the sandbox? This >>>> could be compared to the timer interrupt. In future, this could provide >>>> a way to implement sort of preemptive multithreading. Yes, things get >>>> complicated here since you'll need to implement a scheduler. >>>> >>>> -- Gregory >>>> >>>> >>>> >>>> >>> >>> >> >> > > |
«
Return to Lua-l
|
1 view|%1 views
Loading...
| Powered by Nabble | Edit this page |