On 07.06.2019 21:58, William A Rowe Jr wrote: > I think the optimal way is to allocate a pair of apr thread-specific > wchar buffers in each thread's pool on startup, and use those > exclusively per-thread for wchar translations. We could be looking at > 64k/thread exclusively for name translation, but it doesn't seem > unreasonable. > > The alternative is to continue to use stack, we surely don't want to > lock on acquiring or allocating name translation buffers. /shrug
Since this is Windows, and there's no embedded Windows environment left that I'm aware of that's still alive, we can continue with using the stack ... but wouldn't it be so much better to alloca() the required size instead of blindly burning through 64k every time? Obviously that means counting the characters first. > On Fri, Jun 7, 2019 at 6:27 AM Greg Stein <gst...@gmail.com > <mailto:gst...@gmail.com>> wrote: > > On Fri, Jun 7, 2019 at 6:02 AM <i...@apache.org > <mailto:i...@apache.org>> wrote: > >... > > \@@ -114,116 +93,73 @@ APR_DECLARE(apr_status_t) apr_dir_read(a > { > apr_status_t rv; > char *fname; > + apr_wchar_t wdirname[APR_PATH_MAX]; > > > That's a crazy huge stack frame. I recognize we were doing this > before this commit, but is it advisable? Should it be corrected? > > Cheers, > -g >
