[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: ex API
- From: Chris Marrin <chris@...>
- Date: Mon, 13 Feb 2006 17:36:26 -0800
Mark Edgar wrote:
Some discussion here last month prompted me to design an extended API
for Lua which aims at adding some standard features found in modern
desktop and server operating systems (Windows, UN*X, MacOS). This is
not meant to be a catch-all API for things like graphics or networking,
nor is it meant to be added to the standard Lua distribution. This API
simply provides some base-level operating system function which are not
covered under the C standard, but are so ubiquitous as to be available
on all (non-embedded) systems.
I've written sample implementations for Windows and "POSIX". These
rough yet working implementations are only meant as proof-of-concept,
but with a bit of polish, they could serve as the standard
implementations for these two platforms.
Commence criticism. :)
Sorry I dropped the ball on this a few weeks ago. Thanks for coming up
with a nice strawman.
I am very confused about spawn, as it relates to exec(). I thought
execvp() (which you used for the Linux implementation) replaced the
currently running process with the given file, as stated here:
"The exec family of functions replaces the current
process image with a new process image"
But you used CreateProcess() on the win32 implementation, which I
thought creates a NEW process without affecting the currently running
process. It looks like you want the child process functionality from
Also, there is already a spawn() function on Linux systems, which
behaves similarly to fork(), so maybe this would not be the best name
for this function?
Personally, I have little use for exec(). I find pipe() and system() to
do what I need in these areas. They are horrible, but I can get them to
do what I need! I also have never had any need for an explicit file
lock/unlock semantic. Seems like this is the domain of databases and
transaction processing, so they would fit better in a package like that.
But maybe many others see the utility of this.
I have become partial to Rici's proposal of an environment table with
metamethods to interface it to the system environment. So you would say:
print("user=", os.environ["USER"]) -- for getenv()
os.environ["MY_FAV_COLOR"] = "yellow" -- for setenv()
os.environ["MY_FAV_COLOR"] = nil -- for unsetenv()
FYI, the reason I dropped this is because Fusion needs additional
functionality in our os and io support. Since Emma is web enabled, it
would be a fine virus carrier if we allowed unchecked support for these
two libraries (os.remove("/*") would not make many people happy :-)
So I am implementing a simple Access Control List system around the
affected functions. When you load the "fusion" library it will replace
os and io with versions that are ACL enabled. These versions will also
have the extra functionality we have discussed here.
I will, of course, make all this available to anyone who needs it. But
it will be included in the Fusion package, which is around 200K. I will
try to follow any concensus agreed upon here for compatibility.
chris marrin ,""$,
firstname.lastname@example.org b` $ ,,.
mP b' , 1$'
,.` ,b` ,` :$$'
,|` mP ,` ,mm
,b" b" ,` ,mm m$$ ,m ,`P$$
m$` ,b` .` ,mm ,'|$P ,|"1$` ,b$P ,` :$1
b$` ,$: :,`` |$$ ,` $$` ,|` ,$$,,`"$$ .` :$|
b$| _m$`,:` :$1 ,` ,$Pm|` ` :$$,..;"' |$:
P$b, _;b$$b$1" |$$ ,` ,$$" ``' $$
```"```'" `"` `""` ""` ,P`
"As a general rule,don't solve puzzles that open portals to Hell"'