[Libwebsockets] most recent master commit / breaking changes?

Joel Winarske joel.winarske at gmail.com
Fri Mar 17 07:34:57 CET 2017


This change makes it work again on Windows.  Thanks.

I suspect it's there for widest compatibility.  As at multiple points MSFT
was trying to move away from posix.  I believe the posix subsystem is
missing from WinRT, so it would impact Windows IoT, Windows Phone, etc.



On Thu, Mar 16, 2017 at 8:46 PM, Andy Green <andy at warmcat.com> wrote:

>
>
> On 03/17/2017 11:17 AM, Joel Winarske wrote:
>
>> The code was in one of my plugins.  It just had warnings I chose to
>> ignore.  My bad.
>>
>
> OK.  Well that's one of 'em.
>
>
>> Regarding fstat my exercise indicates that fstat only likes the file
>> handle from open(), opposed to CreateFile(). Running in the debugger, fstat
>> fires an exception; which I originally listed.  stat was used before, and
>> this didn't require a file handle.
>>
>
> Right... of course there is just int fd in Unix.  It got embraced and
> extended...
>
> Do you have an idea why the contributed win32 platform code doesn't just
> use posix open()?
>
>
>> Also stat doesn't require an opened file, where fstat does.  When
>> determining 304 if you don't need to open a file, better perf right?
>> Especially with a SPI, MMC. or eMMC memory device.
>>
>
> Mmm stat() requires the filesystem lookup for the string again which is
> expensive... after doing the same thing for open(), fstat() can bypass that
> and go straight to the inode.
>
>
>> My vote is to factor out fstat and avoid opening the file unless actually
>> needed.
>>
>
> Yeah... clearly something is broken and something needs to happen.
>
> How about this
>
> https://github.com/warmcat/libwebsockets/commit/2e874dea5048
> b192c08f477c00f9053285857f0d
>
> -Andy
>
>
>>
>> On Thu, Mar 16, 2017 at 8:03 PM, Andy Green <andy at warmcat.com <mailto:
>> andy at warmcat.com>> wrote:
>>
>>
>>
>>     On 03/17/2017 10:39 AM, Joel Winarske wrote:
>>
>>         The fstat change came in with
>>         19cc7acb24a1bb402ef3260efa2b64b9357b746a - fops-zip
>>
>>
>>     That fstat change is not special for WIN32 and it works fine on
>>     Linux; fstat() should be the same on Windows.
>>
>>     It looks like the fd is invalid, but that doesn't make sense since
>>     if it can't find the file it will return a NULL fop_fd and we
>>     check for that.
>>
>>
>>
>>         On Thu, Mar 16, 2017 at 7:26 PM, Joel Winarske
>>         <joel.winarske at gmail.com <mailto:joel.winarske at gmail.com>
>>         <mailto:joel.winarske at gmail.com
>>
>>         <mailto:joel.winarske at gmail.com>>> wrote:
>>
>>             Regarding 1, thank you for pointing out the API change.  I
>>             resolved this.  I reverted code changes on 2 to check, and
>>         fstat
>>             is still failing.
>>
>>
>>     OK... it should have blown compiler errors though, since the args
>>     would not match the new declaration in the header.  So that
>>     suggests maybe still problems with your local lws tree diverged
>>     from mine.
>>
>>     git pull is good for following trees with a consistent history.
>>     It's not really useful following master.  Appveyor and Travis only
>>     tell me I have problems after I push stuff, so there is a constant
>>     trickle of fixes coming that way. Rather than mess up the history
>>     with "uhhh... fix NO_SERVER"... "ughhh... fix that fix", I fix
>>     whatever I was pushing directly and repush it.  Sometimes I will
>>     refactor what I have been working on and pushing over several
>>     days, or change the order of the patches in the history (on
>>     master, I leave the vx.y-stable branches to have a consistent
>>     history).
>>
>>     The right way for following this kind of tree is, eg,
>>
>>      $ git fetch https://github.com/warmcat/libwebsockets
>>     <https://github.com/warmcat/libwebsockets> +master:m
>>
>>     This teleports the remote master into a local branch "m". It makes
>>     no effect at all on your local checked-out branch. You can check
>>     what the differences are with your local checked-out branch
>>
>>      $ git diff --stat m
>>
>>     If you want to replace your local checked-out lws with "m" - it
>>     replaces everything with exactly "m", losing any changes you may
>>     have made to lws
>>
>>      $ git reset --hard m
>>
>>     If you think you might want your local changes, you can use
>>
>>      $ git diff m > changes.patch
>>
>>     first to save the differences, or you can leave your old branch
>>     intact and move to a new branch set to m
>>
>>      $ git branch lws7
>>      $ git checkout lws7
>>      $ git reset --hard m
>>
>>     -Andy
>>
>>
>>             On Thu, Mar 16, 2017 at 5:43 PM, Andy Green
>>         <andy at warmcat.com <mailto:andy at warmcat.com>
>>             <mailto:andy at warmcat.com <mailto:andy at warmcat.com>>> wrote:
>>
>>
>>
>>                 On 03/17/2017 05:20 AM, Joel Winarske wrote:
>>
>>                     Hi Andy,
>>                     I just did a pull on master, and now am seeing a
>>         couple
>>                     issues with things on Windows:
>>                     1. When stepping into lws_vfs_file_open *flags ==
>>                     0xcccccccc, not 0. No idea what's up with this. It
>>         fails,
>>                     unless I update the value to 0 in the debugger.
>>                     uint32_t flags = LWS_O_RDONLY;
>>                     fd = lws_vfs_file_open(lws_get_fops(vhd->context),
>>         file,
>>                     &filesize, &flags);
>>
>>
>>                 Where is this code from?  It doesn't seem to exist in
>>         my tree.
>>
>>                 lws_vfs_file_open() now looks like this
>>
>>                 LWS_VISIBLE LWS_EXTERN lws_fop_fd_t LWS_WARN_UNUSED_RESULT
>>                 lws_vfs_file_open(const struct lws_plat_file_ops
>>         *fops, const
>>                 char *vfs_path,
>>                           lws_fop_flags_t *flags);
>>
>>                     if (fd == NULL) {
>>                     lwsl_notice("file not opened %s\n", file);
>>                     return -1;
>>                     }
>>
>>                     2.  Serving is somehow broken.  I haven't changed my
>>                     config file.  Is there a breaking change, or
>>         modification
>>                     required for conf file I missed?  The file is present.
>>
>>                     [2017/03/16 14:08:58:2111] INFO: Method: GET
>>         request for
>>                     '/ui/index.html'
>>                     [2017/03/16 14:08:58:2121] INFO: client indicates
>>         GZIP is
>>                     acceptable
>>                     [2017/03/16 14:08:59:6864] INFO: unable to stat
>>                     C:/etc/lwsws/www/ui/index.html
>>                     [2017/03/16 14:08:59:6874] INFO: LWS_CALLBACK_HTTP
>>         closing
>>
>>                     I get a break point on the last line. This never
>>         happened
>>                     before:
>>                     template <typename StatStruct>
>>                     static int __cdecl common_fstat(int const fh,
>>         StatStruct*
>>                     const result) throw()
>>                     {
>>                         _VALIDATE_CLEAR_OSSERR_RETURN(result != nullptr,
>>                     EINVAL, -1);
>>                         *result = StatStruct{};
>>
>>                         _CHECK_FH_CLEAR_OSSERR_RETURN(fh, EBADF, -1);
>>                         _VALIDATE_CLEAR_OSSERR_RETURN(fh >= 0 && fh <
>>                     _nhandle, EBADF, -1);
>>
>>
>>                 Is this possibly a fallout from 1)?
>>
>>                 -Andy
>>
>>
>>
>>                     Thanks,
>>                     Joel
>>
>>
>>                     _______________________________________________
>>                     Libwebsockets mailing list
>>         Libwebsockets at ml.libwebsockets.org
>>         <mailto:Libwebsockets at ml.libwebsockets.org>
>>                     <mailto:Libwebsockets at ml.libwebsockets.org
>>         <mailto:Libwebsockets at ml.libwebsockets.org>>
>>         https://libwebsockets.org/mailman/listinfo/libwebsockets
>>         <https://libwebsockets.org/mailman/listinfo/libwebsockets>
>>                            <https://libwebsockets.org/ma
>> ilman/listinfo/libwebsockets
>>         <https://libwebsockets.org/mailman/listinfo/libwebsockets>>
>>
>>
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://libwebsockets.org/pipermail/libwebsockets/attachments/20170316/b3bf1911/attachment-0002.html>


More information about the Libwebsockets mailing list