[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: To, be, posix, or, not, posix...?
- From: William Ahern <william@...>
- Date: Wed, 28 Jan 2015 11:32:47 -0800
On Tue, Jan 27, 2015 at 06:56:12PM +0100, Meino.Cramer@gmx.de wrote:
> currently I am experimenting with a embedded system and
> need funktions like sleep, ppoll and such in lua.
> I installed luaposix, because both were documented on the web.
> But there was neither available via luaposix.
> A "search" via luarocks shows different other posix related
> I am confused...
> Is there anything better than luaposix which has more posix stuff...
> Or didn't I understand something fundamental... ? ;)
My luaunix module has a different feature set. Rather than just POSIX it's
more like POSIX+. It includes BSD and GNU interfaces with custom
implementations for platforms like AIX and Solaris so your Lua code remains
portable even when the underlying OS doesn't support something. E.g. it
provides a correct sigtimedwait implementations for systems where it's
It doesn't have sleep or ppoll, but it's a single C file and should be
relatively easy to hack. And I'd happily accept patches.
FWIW, ppoll isn't POSIX, and so definitely would be in luaposix. POSIX only
defines pselect. And unfortunately pselect isn't actually portable in
practice. Specficially, neither OpenBSD nor OS X have a functioning pselect,
and they definitely don't have ppoll. But for luaunix that's not a problem
as long as it can be correctly emulated.
In my cqueues event library, I've implemented a correct pselect which uses
And that could be refactored to implement ppoll, or a ppoll could be
implemented by translating to pselect.
This actually makes me think I should copy that implementation to luaunix so
I can provide pselect and ppoll. I haven't added any polling stuff to
luaunix yet because I use cqueues for polling stuff. Anyhow, here's the
notes from my pselect implementation:
* kqueue-backed pselect for OpenBSD and Apple. Though Apple provides
* pselect in libc, it's a broken wrapper around select which doesn't solve
* the race condition.
* Logical steps:
* 1) check for signals which will be unmasked and deliverable on select;
* 2) if any are pending, allow delivery and return EINTR; otherwise,
* 3) setup kqueue listener before we unblock;
* 4) execute select with specified signal mask.
* o EVFILT_SIGNAL is an edge-triggered filter, which means that if a
* signal is already pending when we add the listener, we won't be
* notified when it's subsequently delivered. The solution is just to
* check the pending set ahead of time.
* o This implementation doesn't try to minimize the signal disposition
* race where the application doesn't use the proper mask/unmask
* pattern. In particular, it calls sigpending earlier rather later.
* In the future it might even optimize by not installing a filter
* for signals already unblocked.