[vlc-devel] [vlc-commits] Add lua console handling code for windows.

[Antoine Cellerier]

On Wed, Feb 08, 2012, Rémi Denis-Courmont wrote:
> Then don't make them concurrent! I do not see any fundamental need for
> concurrent command line and sockets in a singleinterface instance.

It was for the sake of consistency with the unix behavior. We could
decide to make it exclusive on Windows. I don't really care either way.
Whatever people want suits me.

> I can conceive that parsing the command line is easier with Lua than C.
> But I think the I/O should have remained C code. Merging console and socket
> I/O on Linux was already a bit hackish (on old RC). Obviously, it does not
> work on Windows at all.
> 
> > If there were a clean solution I'd gladly use it. There isn't.
> 
> Time-outs ostracism is not my political invention. VLC inherits it from
> Linux. Linux inherits it from the chipsets vendors. This principle is true
> at least for x86 and ARM, the same platform that Windows runs on. So I find
> it hard to believe that Windows would not have a clean event dispatching
> system to avoid polling timeouts.

It seems that you cannot poll for console input on Windows
(nor can you read from the stdin file descriptor).
WaitForSingleObject/WaitForMultipleObjects is the API which needs to
be used. We could probably change the whole socket code for Windows
in order to use the native API which would make it possible to poll
everything at once using those functions. That seems to be quite a major
undertaking and I'm not even sure that it's doable.

> > Now if people don't care that the lua command line interface
> > doesn't work on Windows I can just revert this commit ...
> > but please stop bitching about the fact that it doesn't work
> > on windows (that wasn't aimed at you Rémi).
> 
> > Just to be clear:
> > Socket only mode or unix with console of course does not use any
> timeout.
> 
> Maybe. But the timeouts are exposed to Lua, and Lua gets some Windows only
> code. This is not a good example, nor a good design. As a matter of fact, I
> have not had much help with event handling ever since Zorglub left.

I'd rather have questionable design with working functionality than
correct design and non-functional code. At least we have something that
works now which can be used to move forward.

-- 
Antoine Cellerier
dionoea