August 2015 - Boost - lists.preview.boost.org

Re: [boost] [asio-users] [http] Formal review of Boost.Http
by Niall Douglas 16 Aug '15

16 Aug '15

On 7 Aug 2015 at 19:29, Vinícius dos Santos Oliveira wrote: > > I do not believe Http is ready for peer review for these reasons, and > > I personally would urge you withdraw it until you have fixed these > > issues and then come back to us. If you do not withdraw it, I will > > vote for rejection. > > Can I persuade you to review the Boost.Http design? I'd reject myself if > you find any fundamental flaw on the design and even if you're going to > reject the library because the lack of tooling (not directly related to > design or documentation, which are the most important items on any > library), it'd be useful to know what needs to be addressed on the design > before I submit again (in the case the submission is rejected). I think my earlier email was poorly phrased now I've slept on it. I made my objections seem like they were about portability, when they were really about design and intent of Http. What I should have said was this: Standalone ASIO is the reference Networking TS implementation for standardisation. Http is currently a set of extensions to Boost.ASIO specifically when it *should* be a set of extensions to the reference Networking TS implementation for C++ standardisation. This is why your current design and architecture is flawed, but luckily there isn't too much work to fix this by finishing the port of Http to the Networking TS. The Internet of Things tends to involve lots of small somewhat underpowered internet devices where C++ is likely going to play a much more important role than historically in embedded systems. The chances are that any Networking TS in C++ will be very extensively used in such IoT applications. If there were also a high quality set of extensions adding HTTP support to the Networking TS, I think your chances are good that your Http library would be seriously considered by WG21 for standardisation. *This* is why I very strongly believe that Http needs to cleave itself tightly to the Networking TS reference implementation, and not to Boost.ASIO. Moreover, if you make Http an extension of the Networking TS, you get Boost support with that for free - Http becomes dual use. > About C++03 support, it's not required for Boost acceptance, so I can add > later. I want to increase tests coverage a lot before porting code to > C++03, so I don't introduce accidental bugs in the process. As a strong advocate for C++ 11 over 03 I can understand. However, IoT developers tend to be stuck on some pretty ancient toolsets for longer than others. 03 support I think would greatly increase your potential userbase. > In the case the abstractions I need enter on the C++ standard, maybe your > APIbind will help me. I actually would advise you to choose ASIO's STL abstraction machinery over my own alternative APIBind in this instance. > But I just don't find any reference to BOOST_ASIO_HAS_STD_SYSTEM_ERROR > outside of config.hpp. Even if it was used, it is undocumented, which means > it is an implementation detail that won't be guaranteed to be there forever > (accidental behaviour versus a documented guarantee). I'm pretty sure that implementation detail won't change in a hurry. STL abstraction machinery changes as quickly as a STL does i.e. every decade or so. > > https://svn.boost.org/trac/boost/wiki/BestPracticeHandbook#a7.SAFETY:S > > tronglyconsideranightlyorweeklyinputfuzzautomatedtestifyourlibraryisab > > letoacceptuntrustedinput > > That's why this first implementation uses a proven-parser that is very well > tested. The buck always stops with the top most layer, not internally used third party libraries. You NEED to fuzz test untrusted inputs when parsing HTTP. For all you know, your STL implementation could be the thing with the overflow bug, or the way in which you use it. > > * I don't understand why you cannot issue more than one async read at > > a time nor async write at a time. In something like pipelined HTTP > > that seems like a very common pattern. I smell a potential design > > flaw, and while the docs mention a "queue_socket" I can't see such a > > thing in the reference section. > > > > Too much synchronization and buffering. > > The pipeline has the following requests: > > A => B => C > > If I were to allow replies to request B, the design would be more complex, > increasing the difficult to implement alternative backends and everyone's > life. Also, the reply to request B cannot actually be sent while the reply > to request A is on hold. This means that the whole response to request B > would need buffering and if response B is a video live stream, this means > an implicit (the user cannot know) crash after an unfortunate memory > exhaustion. I couldn't claim a **lightweight** server if this excessive > buffering was to occur. I couldn't claim the project is appropriate for > embedded devices if I had chosen the buffering approach. It's a trade-off. > I should write about it in the "design choice" of the documentation. > > HTTP/2.0 does have proper multiplexing and it can be more useful to respond > several requests without "head of line blocking". Ok, let's accept that HTTP before 2.0 can't multiplex (not my experience personally, but I agree it's got big gotchas before 2.0). You need a user facing API for Http which lets user code multiplex where that is available, and not multiplex when that is not available. In other words, identical code written against Http must automatically be optimal in either connection case. You're probably going to ask how I might implement that right? I think my first guess is you need two completion handler layers and therefore two completion dispatcher reactors: the bottom layer is the same as ASIO's and uses the ASIO reactor, whilst the top layer which users of Http sees is a reactor operated by Http and is disconnected, though operated by, the ASIO reactor. > A queue socket is a concept, I don't provide one. I can look into how make > the documentation less confusing by adding a page exclusively dedicated to > explain the problem it solves. Would that work for you? It could be this queue socket concept of yours is exactly what I just proposed as two completion handler and reactor layers. In either case, I don't think queue sockets should be a concept, I think they need to be the core of your library's user facing API. If power users wish to bypass that user facing API layer for less hand holding and less latency, that should also be possible. But I think HTTP multiplexing should be assumed to be the default starting point for Http applications. Once HTTP 2.0 is more common, it will seem madness that Http's user facing API is _not_ 100% multiplexing. > * Your tutorial examples use "using namespace std;" at global level. > > That's a showstopper of bad practice, and you need to purge all of > > those. Same for "using namespace boost;" at global level. > > > > The tutorials should be as small as possible to not scary the users. > > But I can put a comment "you should avoid using namespace". Does it help? using namespace is fine at local scope. It's not fine at global scope. Replacing all global using namespace with local using namespace is all you need to do. > * Your reference section is one very long thin list. You might want > > to use more horizontal space. > > > > I'd be happy already if I knew hot to remove the TOC from the reference > page. It'd be much more clean already. Personally in AFIO I hack the CSS to make the list into columns. ASIO employs a table. There are many solutions. > * I personally found the design rationale not useful. I specifically > > want to know: > > > > 1. Why did Http choose ASIO as my base over leading competitor X > > and Y? > > 2. What sacrifices occurred due to that choice? i.e. things I'd > > love weren't the case. > > > > I assume I don't need to reply these questions during the review, given the > reviewers may already be experienced on the answers. Well ... I'm not sure that's actually the case. It's not we don't have opinions on the answers, it's whether our answers are different to your answers. You'll see this during the AFIO review later this month - I have some really weird opinions no one else shares like choosing my own custom lightweight monadic future-promise implementation over async_result. That will be the source of much criticism I'm sure. > 3. What alternatives may be better suited for the user examining > > Http for suitability and why? i.e. make your documentation useful to > > people with a problem to solve, not just a howto manual. > > > > I don't quite understand this point. What I'm really asking is for details of when before starting Http you reviewed the options available and the designs they used, and exactly why you chose the design choices in Http you did with reference and comparision to prior art. Like a literature review, but for programming libraries. Does this make sense? It's partially for us to help us understand your choices, but also to help those examining Http to see if it's useful to them to figure out the best solution to their problem (which may be to use an alternative to Http). Documentation which is useful over documentation which is reference. > * Benchmarks, especially latency ones which are important for many > > uses of HTTP are missing. I'd particularly like to know confidence > > intervals on the statistical distribution so I know worst case > > outcomes. > > > > These values will change when I replace the parser used now. Also, they can > change based on the buffer sizes and parser options, which the user is/will > be able to change. > > Nevertheless, I do want to do some serious benchmarking, specially because > it'll give me a reference point when I write my own parser and want to > compare performance speedup. I can do some poor benchmark this weekend and > show the results. That would be interesting, but don't go crazy on it. Also, please do enable the undefined behaviour sanitiser permanently including in release mode and with full stack smashing protection before running benchmarks. Anything parsing malicious input should have all those turned on where available. > I hope all the above isn't too disheartening Vinícius. > > Not at all. I think you're the second person to dedicate more time > reviewing my work and this isn't disheartening at all. Just that your > feedback is usually around tooling and not the design itself (everybody has > its preferences). That's because I like the design a lot and have little bad to say about it. I've also been subscribed to your github since the beginning, and I have been reviewing your code on and off as you wrote it. You're a talented programmer. > > Jamfile for the main library build, > > Consider this done. I won't integrate into Boost without removing CMake > first. This was already partially stated in the Bjorn's announcement (but > somehow implicit, to be fair). I have no problem at all with dual build systems if you're happy keeping both maintained. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

3 6

Re: [boost] [asio-users] [http] Formal review of Boost.Http
by Niall Douglas 15 Aug '15

15 Aug '15

On 13 Aug 2015 at 8:58, Vinícius dos Santos Oliveira wrote: > First of all, sorry to all members of the list about my unavailability. I > was planing to write an experimental HTTP 2.0 backend, so I could give more > confidence about how much I believe this Boost.Http core I present for > review is the right abstraction. > > Anyway, looks like I took the wrong approach. I should have answered the > easiest questions first and implement the HTTP 2.0 backend (experimental, > using existing-library and not Boost-quality) later. That's a wise move Vinícius I think. > > Where I'm really at is I think if Http is accepted you're going to > > either have to ditch it and reimplement atop the Networking TS as > > Chris folds the substantial changes WG21 will force onto ASIO into > > Boost.ASIO, or end up refactoring Http to cleave more closely to the > > Networking TS anyway. > > I'm okay with that. You may be, but I would worry about your users. Boost users expect stability and permanence. > > I think for the majority of HTTP users they just want it to work > > without surprises to a high default performance level. If you look at > > the history of the HTTP library support in Python you'll see what I > > mean - firstly, it's surprisingly easy to get a HTTP library API > > design wrong, even in a v2 refactor. And secondly that people need > > both a stupid-simple API and a more bare metal API *simultaneously* > > with HTTP, and therein lies the design gotcha. > > > > If you want a high level API, you're going to use coroutines. There is > nothing in the wild so readable as coroutines. Coroutines are **the** > solution to solve spaghetti code in asynchronous abstractions. Lambdas and > futures will never be as readable as coroutines. Anyway... God no. I would see a top level API as being synchronous, so something like python's urllib3: import requests r = requests.get('http://www.boost.org') print(r.json()) It may coroutinise but still appear to be synchronous, but that's a separate moving ball and not one Http can tackle alone. > The more I think, the more I believe how much such "middle-level" API is > underestimated. > [snip] > It's not really like Boost.Http is too low level. It's more like only the > less polemic building blocks are available now. You'll see the same main > players in a higher-level abstraction and the main difference is most > likely that you won't manage the main players yourself. Think of it as a Boost user. The average Boost user is going to see Boost.Http and think to themselves, "oh goody I can now write: import requests r = requests.get('http://www.boost.org') print(r.json()) ... in C++ and yay I've just chopped 10,000 lines of buggy hack code from my codebase." And that's exactly what I would expect too from a library called Boost.Http. What you're providing isn't that though: it's a set of low level HTTP related extensions to Boost.ASIO. From my review of your code and docs, and what you've told me, I think the ideal location for your library is within ASIO under the asio::http namespace. However, assuming Chris isn't keen to allow that as a git submodule within ASIO (he might be, I don't know), I think as a very minimum you need a name for your library which says it is a set of low level HTTP related primitives for Boost.ASIO. That name is not Boost.Http for sure. A later library you might submit could be called Boost.Http, but it would provide a daft easy API like the above for Python's urllib3. In fact, if you can achieve a more appropriate name choice, I'll change my vote from rejection to a conditional acceptance as you've done a great job in persuading me from where I was. You've impressed with me your awareness of the tradeoffs involved in a moving API environment, and though I severely personally disagree with your choice of Boost.ASIO over ASIO, I can also see that targeting a more stable API in the form of Boost.ASIO for now makes sense. How does that sound? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

2 1

Making the Windows binaries 'official'
by Tom Kent 15 Aug '15

15 Aug '15

<history> After the boostpro.com organization dissolved, there was never an official place to go to get pre-built binaries for the releases. Some random components were made available on the sourceforge download page and I had been hosting them on my own website (http://boost.teeks99.com) since I started building them around the release of 1.37. A couple years ago, before the release of 1.54, I asked the community if they would like my builds to be hosted on the sourceforge site, and the answer was positive: http://lists.boost.org/Archives/boost/2013/04/202460.php Since the 1.54 release, I've generally been uploading the windows binaries based on the RCs and enabling the downloads just a few minutes after the release notice goes out. </history> I would now like to propose that we make these libraries an official part of each Boost release. I don't think this entails much, just the following: 1) Have the release team coordinate with me to ensure that the binaries are ready before announcing the release. 2) Include a link to them in the release announcement. 3) Link to them from the website. It would also be good to get others who can run the scripts to perform the build, if I am someday unable to do this. The biggest hurdle here is having a (virtual) machine with all six versions of visual studio on it. Is this something the community would be in favor of? I know that many of the people on these lists don't use windows and if they do are generally capable of building the windows binaries themselves, however there is a large group out there that prefers to just get the installer for them (like they do for other projects like Qt, wxWidgets, etc). Thoughts? Tom Kent

2 2

[job] exec job-graphs in a NUMA env (was a thread pool that allows recursive calls)
by Oliver Kowalke 15 Aug '15

15 Aug '15

This library is related to the posting 'a thread pool that allows recursive calls' (http://lists.boost.org/Archives/boost/2015/06/223426.php) e.g. the library solves the many-dependent-jobs problem. boost.job is a derivative work of boost.task (which was published in 2008, the code is refactored and now split into boost.context, boost.coroutine2/boost.fiber and boost.job). boost.job provides a framework for asynchronous execution of job-graphs (a job is a small unit of code that can be executed independently and parallel, e.g. it's a fain-grained work item) of arbitrary dependency, e.g. solving the many-dependent-jobs problem (M: worker threads, N: jobs waiting for other jobs; M << N). Each (logical) processor of a dedicated processor set (configurable) gets a worker-thread assigned. Each worker-thread runs a fiber-pool (launch policy is customizable). A submitted job is always executed by a worker-fiber. While using boost.fiber jobs are scheduled cooperatively so that a job can yield to other jobs during its execution. Jobs can be synchronized via primitives like mutex's, conditions, barriers and channels (message exchange) from boost.fiber without blocking the worker-thread. Fibers provide a fast context switch. boost.job supports to inspect the NUMA topology (e.g. which logical processors are online, and which processors share L1/L2/L3 cache). This information can be used to select a appropriate processor for a job. For a fast access to job related data, boost.job provides functions and classes to allocate memory on NUMA nodes (processors of a NUMA node share cache and have a faster access to its associated memory bank than processors of other nodes.). source: https://github.com/olk/boost-job documentation: http://olk.github.io/libs/job/doc/html/

2 2

Re: [boost] Build Error VS14 + Intel 15.0 (Update 4, the latest)
by degski 15 Aug '15

15 Aug '15

Changing intel-win.jam, line 476 (boost 1.59.0 rc2) from: .iclvars-15.0-supported-vcs = "12.0 11.0 10.0 9.0" ; to: .iclvars-15.0-supported-vcs = "14.0 12.0 11.0 10.0 9.0" ; solves the problem.

2 1

Master branch is open for changes
by Marshall Clow 14 Aug '15

14 Aug '15

The release has been tagged, and library maintainers are free to merge to release again. Thanks to everyone for their cooperation. -- Marshall

1 0

Boost 1.59.0 has been released
by Marshall Clow 14 Aug '15

14 Aug '15

Release 1.59.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains two new libraries and numerous enhancements and bug fixes for existing libraries. New Libraries * Convert: An extendible and configurable type-conversion framework, from Vladimir Batov. * Coroutine2: from Oliver Kowalke For details, including download links, see http://www.boost.org/users/news/version_1.59.0 You can also download directly from SourceForge: http://sourceforge.net/projects/boost/files/boost/1.59.0/ To install this release on your system, see http://www.boost.org/doc/libs/release/more/getting_started/index.html Thanks, --The Boost release team Vladimir Prus Rene Rivera Marshall Clow Eric Niebler Daniel James Beman Dawes

5 4

[filesystem] proposal: treat reparse files as regular files
by Paul Harris 14 Aug '15

14 Aug '15

Hi all, -- Proposal -- tl;dr : I propose that we treat all non-symlink "reparse_files" as "regular_files". If the boost library user wants to do something special with these plain reparse files, they should use alternative means. But typically they are supposed to be treated as regular files. This means we could drop the "reparse_file" enum, or continue to use it for a special-case whats_my_real_status() function. --- Motivation --- Windows Server 2012 uses reparse points to implement deduplification. Those files should be treated as regular files in all circumstances. Currently, they are not classed as "regular" files, so fs::copy() will skip those files, and library-user code written to list files based on official examples will ignore all dedup'd files. This is causing serious and latent problems at the user end, because deduping only happens occasionally after X days, and users cannot easily check if a file is dedup'd (they look just like regular files). --- Real life example --- Another example of reparse use is the "Symantec Enterprise Vault" (version 10), which I found running on one site. It replaces files on the server with reparse-point files. FSUTIL REPARSEPOINT QUERY filename.txt shows the contents of the reparse buffer, which is a URL to an internal HTTP server. The url points to a .asp link with a bunch of codes and dates to identify the file in the server. Copy-pasting that URL into a webbrowser allows you to directly download the file via the webbrowser, which is pretty neat I suppose. In this case, the reparsed-files in Windows Explorer all have grey X crosses on their file icon. If you "type" them (via cmd) or open them, the icon loses the grey cross and the file is no longer a reparse point file. My software refused to read the files because they were "not regular files". Once I adjusted the boost code (described below), my software saw them as regular and opened the files. The file icons lost the grey cross. SO it seems that the file server automatically downloads and replaces the files with the stored content on demand, and the file reading client program should really just treat these files as normal files. --- Short logic --- reparse files (that are not symlinks) should almost always be treated as plain files. They are a mechanism for MS file servers to store files in clever ways, but the client should not care and just read/write them as if they were normal files. This is different to all the other "other" files which can't be treated like normal files: block, character, fifo, socket, unknown So, reparse files should not be grouped with the "other" file types. They are also NOT symlinks, and should not be treated as symlinks (which would require special decisions for copying, or querying the status, or checking if the target still exists). --- What are reparse files --- I did some reading, if I understand correctly: Reparse points give drivers (on the server) a chance to get data through some other specialised means (eg query from a cluster store). They are processed by the server, not the client, so clients should treat reparse data as opaque data. EXCEPT for symlink reparse files. https://msdn.microsoft.com/en-us/library/dd541667.aspx quote:"The following reparse tags, with the exception of IO_REPARSE_TAG_SYMLINK, are processed on the server and are not processed by a client after transmission over the wire. Clients should treat associated reparse data as opaque data." It seems like the rest of the tags are used for connecting files to other types of storage (eg long term storage, cluster storage). Clients may need to do something special with SOME reparse point files, IF the client cares about how long the file read may take. https://msdn.microsoft.com/en-us/library/windows/desktop/aa365505(v=vs.85).… quote: "Most applications should take special actions for files that have been moved to long-term storage, if only to notify the user that it may take a while to retrieve the file." --- Changes required --- Option 1: change is_regular_file() to return true where type==reparse_file I don't like this option, as library-users could be checking the type directly instead of using is_regular_file(). Option 2: These functions return reparse_file: fs::file_type query_file_type(const path& p, error_code* ec) file_status status(const path& p, error_code* ec) file_status symlink_status(const path& p, error_code* ec) They should instead return regular_file instead. --- How to test with dedup files --- Creating dedup'd files is a feature only available on Windows Server 2012, I believe, although Windows XP/Vista/7/8/10 clients all can read dedup files. Here is how I created a windows server to test with (for free!) on a demo Azure cloud server. I have one working, so if anyone would like to use it for their testing, let me know. Step one: follow this blog article: http://blogs.technet.com/b/tommypatterson/p/azureservertrial.aspx once the machine was "running" I clicked Connect at the bottom. That gave me an .rdp file which in theory I could use with rdesktop, but it uses a DNS name that was only just created, so that didn't work. When you click the name of the server in the list, it shows the public IP on the right.. and the port then you can do this $ rdesktop that.ip.addr:port But only if you have the latest rdesktop AND you have set up kerberos something-something. Instead I found a windows computer and used remote desktop from there. --- Once inside, in the "Server Manager --> Dashboard" window on the screen, click "Add Roles" then go next next until "Server Roles" expand "File and Storage services" , "File and iSCSI" , and tick "Data Deduplication" Then next next etc and Install. Wait a bit... and its done. http://www.techrepublic.com/blog/data-center/configuring-windows-server-8-d… --- Continuing on that webpage... Time to enable dedup. There is a temp disk D: so lets enable there. Method 1... I did this and then went to method 2... Start PowerShell, type: "Enable-DedupVolume D:" Method 2... in that same Dashboard, hit the 4th button (File and Storage Services) Then Volumes --> Disks click Volume 1 at the top, and then right click D: at the bottom --> Configure Dedup. To try and accelerate this puppy, I set the "age to dedup" to 0 days. http://www.techrepublic.com/blog/data-center/windows-server-2012-deduplicat… --- Time to make something to dedup. We'll just duplicate the warning.txt file that exists on D: In powershell: PS> D: PS> $file = Get-Content DATALOSS_WARNING_README.txt Then, do these 2 commands a bunch of times until "big.txt" gets to say 6MB PS> Add-Content big.txt $file PS> $file = Get-Content big.txt Then use windows explorer (or other) to make a dozen copies of big.txt Copy c:\windows\explorer.exe to D: to give it something to dedup Go to D: and then copy-paste explorer.exe a dozen times. In PowerShell, type: PS> Update-DedupStatus -Volume D: PS> Start-DedupStatus -Type Optimization -Volume D: and then wait for it to finish. you can track its progress with: PS> Get-DedupJob PS> Get-DedupStatus -Volume D: --- So, once its deduped, you check. PS> FSUTIL REPARSEPOINT QUERY big.txt you should see that its a reparse point with that 0x800etc0013 code. Copy-paste big.txt to big2.txt and check it with the query, and it should tell you big2 is NOT a reparse point. NOW you have some files to test the boost library... You can't zip them up (they lose the dedup tag), you have to run boost binaries ON the computer in the sky. --- Finish --- Thanks for reading, Paul

5 30

[COre] Pull request for enable_if_type
by Joel FALCOU 13 Aug '15

13 Aug '15

Hi, I just refurbished and pushed an old patch adding the enable_if_type SFINAE utility to core. https://github.com/boostorg/core/pull/15 I tried to keep it simple and make the doc proper. This utility has been laying around various boost library and was "reinvetned" in bosot.SIMD. I think it's worth being in core so code duplication is kept to a minimum. Comments welcome

2 3

[spirit] 1.59.0 rc3: compiler warning in real_impl.hpp
by Tobias Loew 13 Aug '15

13 Aug '15

Hi, with MSVC 11, 32-bit build I get a compiler warning in boost\spirit\home\qi\numeric\detail\real_impl.hpp : 287 warning C4244: '=' : conversion from 'unsigned __int64' to 'double', possible loss of data since I usually comile with warnings-as-errors this broke my build. Tobias -- View this message in context: http://boost.2283326.n4.nabble.com/spirit-1-59-0-rc3-compiler-warning-in-re… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 3