On 31 August 2018 at 14:59, Russell Haley <russ.haley@gmail.com> wrote:
> The cqueues author William Ahern made the suggestion to use wepoll[1]
I do not recall this; do you have a citation?
From a private email:
"... I haven't had much time to dedicate to cqueues
or my other projects. I'm hoping that'll change soon. What got me thinking
about Visual Studio again was this project,
https://github.com/piscisaureus/wepollwhich might make a Windows port practical."
It looks like this library came to maturity after you documented your issue 35? It looks like you've already been in discussion with @
piscisaureus.
> My working assumption (from Mr. Ahern) is that if I can get the base cqueues/src/lib/ library working with sockets, we have a fair shot of getting lua-http on Windows. So, this effort is strictly about compiling src/lib so far.
That is not the biggest blocker. Infact aside from kpoll.c the things
in src/lib should already compile for windows.
From the build output:
dns.c
c:/Users/russh/git/cqueues/src/lib/dns.c(51): fatal error C1083: Cannot open include file: 'strings.h': No such file or directory
and
c:/Users/russh/git/cqueues/src/lib/notify.c(26): fatal error C1083: Cannot open include file: 'config.h': No such file or directory
socket.c
c:/Users/russh/git/cqueues/src/lib/socket.c(41): fatal error C1083: Cannot open include file: 'sys/select.h': No such file or
Perhaps I've done something incorrectly. Maybe I'll throw the code into a VS project and see if these compilation errors are mistakes on my part.
> I included wepoll.c/h and queue.h (from freebsd 10) in kpoll.c, which seems to be the guts of the polling library.
Currently kpoll.c is unused! See https://github.com/wahern/cqueues/issues/24
D'oh! Thanks for the heads up. I'll have a look at cqueues.c
> Much of the epoll calls compile(?), but the code paths defined under PORTS and #else don't compile so I've just commented them all out (whack!). I've included a git patch and my build output can be found here: https://pastebin.com/9hLSpzGL.
That doesn't really make sense. the epoll vs ports code paths are
alternatives selected with the C preprocessor, it's not possible to
use both.
That's what I thought too but as I went through the code, the failures seemed to be from defined sections that shouldn't have even been compiled. To be sure, I may have ham-fisted something but removing the code paths was the shortest route to getting the code to compile and that was/is my only concern at this "prototyping stage".
-------------------
The large task of porting cqueues to windows is well documented in
https://github.com/wahern/cqueues/issues/35
Great, I'll start digging a little.
The lowest-common-denominator way forward seems to be following
https://github.com/wahern/cqueues/pull/185
which is to allow :pollfd() to return an fd *set*.
A different way to do things would be to write a windows thead-based
epoll implemention. This requires someone with deep win32 and nt.dll
knowledge.
This library implements the epoll API for Windows applications. It is fast and scalable, and it closely resembles the API and behavior of Linux' epoll.
Unfortunately it only supports sockets at the moment, but I'm hoping that would be enough to move forward?
I haven't pursued either of these due to time constraints and the
simple answer that I don't use windows, so I wouldn't be developing
for myself.
I remember that one of the sailor maintainers was curious about using lua-http but the lack of Windows compatibility made that suggestion a non-starter.
I doubt I have the skills to actually bring this to fruition (and honestly don't have a need for a Windows based lua http server), but it's something to hack at and a good practical application for learning JamPlus. What can I say? It bugs me that it's not portable, I'm a sucker for punishment...
Russ
