On Tue, Jun 11, 2019 at 5:38 PM William A Rowe Jr
wrote:
> On Tue, Jun 11, 2019 at 1:44 PM Branko Čibej wrote:
>
>> We either reserve about 2x buffers for file name transliteration in heap
>> per thread, or we use the thread stack. As long as we trust that our utf-8
>> to ucs-2 logic is rock
On Tue, Jun 11, 2019 at 1:44 PM Branko Čibej wrote:
> We either reserve about 2x buffers for file name transliteration in heap
> per thread, or we use the thread stack. As long as we trust that our utf-8
> to ucs-2 logic is rock solid and the allocations and limits are correctly
> coded, this
On Tue, 11 Jun 2019 at 17:14, William A Rowe Jr wrote:
>
> On Tue, Jun 11, 2019 at 4:15 AM Branko Čibej wrote:
>>
>> 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
On Tue, Jun 11, 2019 at 9:14 AM William A Rowe Jr
wrote:
> On Tue, Jun 11, 2019 at 4:15 AM Branko Čibej wrote:
>
>> 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
On Tue, Jun 11, 2019 at 4:15 AM Branko Čibej wrote:
> 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
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
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
On Fri, Jun 7, 2019 at 6:02 AM 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
