[Libwebsockets] most recent master commit / breaking changes?

Andy Green andy at warmcat.com
Fri Mar 17 08:10:25 CET 2017



On 03/17/2017 02:34 PM, Joel Winarske wrote:
> This change makes it work again on Windows.  Thanks.

OK... thanks for letting me know.  It's a bummer... I guess I will make 
a 2.2.1 shortly.
>
> 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.

I didn't have anything to do the windows support on lws, it was 
contributed by "popular demand"... there are have been users of it 
contributing patches for variants like wince.  RT and phone seemed to 
sink without a trace which is encouraging to me.

-Andy

>
>
>
> On Thu, Mar 16, 2017 at 8:46 PM, Andy Green <andy at warmcat.com 
> <mailto: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/2e874dea5048b192c08f477c00f9053285857f0d
>     <https://github.com/warmcat/libwebsockets/commit/2e874dea5048b192c08f477c00f9053285857f0d>
>
>     -Andy
>
>
>
>         On Thu, Mar 16, 2017 at 8:03 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 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>>
>                 <mailto: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>
>             <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>>
>                     <mailto: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>>
>                             <mailto: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/mailman/listinfo/libwebsockets
>         <https://libwebsockets.org/mailman/listinfo/libwebsockets>>
>                                  
>          <https://libwebsockets.org/mailman/listinfo/libwebsockets
>         <https://libwebsockets.org/mailman/listinfo/libwebsockets>
>                
>         <https://libwebsockets.org/mailman/listinfo/libwebsockets
>         <https://libwebsockets.org/mailman/listinfo/libwebsockets>>>
>
>
>
>
>
>
>
>




More information about the Libwebsockets mailing list