Hey Michael, 2008/11/13 Michael Sørensen Loft <[EMAIL PROTECTED]>: > I am using wt in an embedded application and therefore I have limited memory. > I need to provide download of files and for that I use a WFileResource. >From > looking at the implementation of WFileResource, it seems that the entire file > needs to fit in memory. The file is read until no more data is returned from > the file stream before the streamResourceData method returns.
You are right about the need for the file to fit in memory (because we are actually streaming to a stringstream in case of a wthttpd which is subsequently converted to a string buffer). The main problem is that there is a big difference in optimizations you want to do on an Intranet/Extranet versus an embedded system: On the internet/extranet, we may need to handle many concurrent requests, from possibly slow connections. This is ideally done by using async I/O so that no single connection blocks a thread, and this is how we currently implemented it: the whole response is first buffered and then transmitted within the boost::asio framework asynchronously. In an embedded system, on the other hand, we want to minimize memory usage, usually have only few concurrent requests, and the clients may typically have a faster connection. So there it would make more sense to directly stream the result using synchronous I/O. > The documentation for streamResourceData says, that the method should return > false if not all data has been streamed. I have modified WFileResouce to > behave this way and to know if a file has been partly streamed (see code > below). But when I use this modified version, the file download stalls and if > I quit the web application, I can see that only the first chunk of the file > has been sent. I have been debugging the app, an I can see that the > streamResourceData method is only invoked once and not multiple times as I > would expect. This is not clear from the documentation, but by returning false, you simply indicate that the connection should stay open and that more data may become available at some other time (when you call flush()). The intended scenario is server-push (and given that this is an internal affair in Wt, perhaps this extra complexity should have stayed out of the public API). I suggest that we make a build configuration option for the wthttpd that allows the choice between either scenario (transmitting a buffer using async I/O versus directly streaming using sync I/O). The latter option would then be more suitable for embedded systems. Good ? Regards, koen ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ witty-interest mailing list witty-interest@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/witty-interest
