[Libwebsockets] polling for file descriptor i/o
andy at warmcat.com
Mon Mar 6 07:48:04 CET 2017
On 03/06/2017 02:32 PM, Per Bothner wrote:
> On 03/05/2017 06:14 PM, Andy Green wrote:
>> The "fops signature" scanning is done in common library code not in
>> the zip fops open, it checks everybody in the linked-list excepting
>> the first, platform fops. Basically user-provided fops will be
>> treated the same as internal ones for selection based on signatures
>> in vfs path.
>> And this stuff should work even on oldstyle "manual" user code
>> without mounts, if they use lws_vfs_file_open().
>> I confirmed it can serve with .zip or .jar as the mount origin.
>> These changes are all internal to lws from the POV of your code now
>> AFAIK, you should be able to delete the symlink and use the .jar
>> Plus or minus bugs I think that's it now.
> I got it working, but I'm not sure it's quite right.
> In the lws_http_mount for the origin field I had to
> end the name with a '/', as in:
Hm yes not needed in the test example...
> This does not match test-server/test-server-v2.0.c, where the
> origin does not end in a '/'.
> Then when lws_fops_zip_opened I get:
> Breakpoint 1, lws_fops_zip_open (fops=0x63ae60,
> vpath=0x7fffffffc1b7 "/hlib/domterm-core.css",
> I.e two slashes "//" before the hlib (which is ugly but doesn't
> matter), so that
> vpath can start with a '/' (as requires by the following comment.
> The uri in the call to lws_http_serve does not start with a '/',
> which may be the issue:
I think I found it, please refetch master.
I also did some valgrind and coverity testing, the latest master has
those fixes too.
> #1 0x00000000004209b6 in lws_http_serve (wsi=0x65e650,
> uri=0x640281 "hlib/domterm-core.css",
> m=0x638620 <mount_domterm_zip>)
> As I said: It works, but I'm not sure that this is how it is supposed
> to work.
No there shouldn't be any / at the end of the mount .origin.
More information about the Libwebsockets