On Fri, 26 Apr 2024 at 14:56, Daniel Sahlberg
wrote:
> Den tors 25 apr. 2024 kl 18:20 skrev Ivan Zhakov :
>
>> Hi,
>>
>> I am currently working on CMake and vcpkg [1].
>>
>> One problem that I noticed is that APR 1.7.x (and APR-Util 1.6.x)
>> insta
, but maybe it's overkill?
[1] https://vcpkg.io/en/
--
Ivan Zhakov
On Mon, 22 Apr 2024 at 17:01, Joe Orton wrote:
> On Sat, Apr 20, 2024 at 12:38:20PM +0200, Ivan Zhakov wrote:
> > I would suggest separating APR in different libraries, while keeping them
> > in one project/source tree.
> >
> > Something like that:
> > - apr-
On Mon, 22 Apr 2024 at 14:41, Graham Leggett wrote:
> On 22 Apr 2024, at 12:52, Ivan Zhakov wrote:
>
> The question is, is it worth it for such a marginal change?
>> Have you looked in to the practicalities and verified no major stumbling
>> blocks,
>> bearing in
On Mon, 22 Apr 2024 at 11:03, Nick Kew wrote:
>
>
> > On 20 Apr 2024, at 11:38, Ivan Zhakov wrote:
> >
> > Hi,
> >
> > In APR 2.0 we merged APR-Util **project** to APR. Which is IMHO a good
> thing.
>
> Um, apr-util was a separate library, but no
-2 (?)
- apr-crypto-2
- apr-xml-2
- apr-ldap-2
- apr-memcache-2
- apr-redis-2
I want to clarify that I don't propose going back to apr-util time when APR
was splitted to separate projects: this proposal is only about libraries on
the disk.
What do you think?
--
Ivan Zhakov
gt; D:\a\apr\apr\build\Debug\testall.exe : fatal error LNK1120: 1 unresolved
> externals [D:\a\apr\apr\build\testall.vcxproj]
>
> I fixed it in r1917104 <https://svn.apache.org/r1917104>.
PS: Maybe it makes sense to switch to using CMake for all platforms to
avoid such problems in future...
--
Ivan Zhakov
wise I will ask here for help.
>
> We had a regression in apr-1-config that is now fixed and we have some
> nice fixes / improvements for Windows.
> I know that people think of releasing 1.8., but another 1.7 release seems
> to be the lower hanging fruit.
>
>
> +1.
--
Ivan Zhakov
[Define if pthread_setname_np is available])
> > +fi
> > +])dnl
> > +
>
> Thsi configure check does *not* fail for me on SLES 11 where
> pthread_[gs]ername_np is not available. In config.log I find
>
> warning: implicit declaration of function ‘pthread_setname_np’
>
> but configure procees with a "yes". The buidl then succeeds, but the
> library is not usable due to the unresolvable symbol.
>
> Best regards,
>
> Rainer
>
--
Ivan Zhakov
06889 <https://svn.apache.org/viewvc?view=rev=1906889>
implements apr_thread_name_set() and apr_thread_name_get() for Linux
and Windows.
--
Ivan Zhakov
/* size: 40, cachelines: 1, members: 5 */
> /* sum members: 32, holes: 2, sum holes: 8 */
> /* last cacheline: 40 bytes */
> };
>
> Nice, but I'd like to note that this change breaks ABI and can be released
only in APR 2.0.
--
Ivan Zhakov
On Thu, 16 Jun 2022 at 21:06, Ivan Zhakov wrote:
> On Wed, 5 Jan 2022 at 21:37, Ivan Zhakov wrote:
>
>> On Mon, 13 Sept 2021 at 11:57, Johan Corveleyn wrote:
>> >
>> > On Tue, Sep 7, 2021 at 3:58 PM Johan Corveleyn
>> wrote:
>> > >
>>
On Tue, 12 Jul 2022 at 12:01, Ivan Zhakov wrote:
> I have implemented new apr_thread_name_get()/apr_thread_name_set() API in
> branch 'thread-name':
> https://svn.apache.org/repos/asf/apr/apr/branches/thread-name/
>
> Implementation is based on patch in issue 60587 [1]. Curren
On Fri, 20 Jan 2023 at 03:44, Eric Covener wrote:
> 1.7.1-rc1 is here:
>
> https://apr.apache.org/dev/dist/
>
> For the release of apr-1.7.1
> [X ] +1 looks great!
> [ ] -1 something is broken
>
> +1 (Windows)
--
Ivan Zhakov
oth approaches.
Btw I've recently backported several fixes to 1.7.x branch:
[[[
*) Fix attempt to free invalid memory on exit when apr_app is used
on Windows. [Ivan Zhakov]
*) Fix double free on exit when apr_app is used on Windows. [Ivan Zhakov]
*) Fix a regression in apr_stat() for root path on Windows. [Ivan Zhakov]
]]]
And CMake/GitHub Actions stuff.
--
Ivan Zhakov
k out the back-out as needed? Otherwise I ask the project
> member's permissions to work from a new 1.7.x-rebuild branch
> for the following week based on 1.7.0, and replace 1.7.x with
> the 1.7.x-rebuild branch one week later.
>
> I hope none of us are looking to land in this quicksand again,
>
> +1.
--
Ivan Zhakov
On Wed, 29 Jun 2022 at 01:28, Yann Ylavic wrote:
>
> On Tue, Jun 28, 2022 at 6:08 PM Ivan Zhakov wrote:
> >
> > On Tue, 28 Jun 2022 at 00:24, Yann Ylavic wrote:
> > >
> > > Hi Ivan,
> > >
> > > On Mon, Jun 27, 2022 at 8:19 PM Ivan Zhakov
and
pthread_getname_np(). It also supports Windows 10, version 1607 or later.
I think the branch is ready to be merged into the trunk.
Thoughts?
[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=60587
--
Ivan Zhakov
On Fri, 8 Jul 2022 at 19:15, Ivan Zhakov wrote:
>
> On Thu, 30 Jun 2022 at 20:14, Ivan Zhakov wrote:
> >
> > > > > I think that we could try an alternative approach for that part of
> > > > > the problem. The alternative approach would have the same
On Thu, 30 Jun 2022 at 20:14, Ivan Zhakov wrote:
>
> > > > I think that we could try an alternative approach for that part of the
> > > > problem. The alternative approach would have the same characteristics
> > > > as the approach that had been used for
à la apr_socket_sendv()?
>
[[[
Each buffer must be at least the size of a system memory page and *must be
aligned on a system memory page size boundary*. The system writes one
system memory page of data from each buffer.
]]]
[[[
The total number of bytes to be written. Each element of aSegmentArray
contains a one-page chunk of this total. Because the* file must be opened
with FILE_FLAG_NO_BUFFERING*, the number of bytes must be a multiple of the
sector size of the file system where the file is located.
]]]
--
Ivan Zhakov
On Fri, 24 Jun 2022 at 14:21, Yann Ylavic wrote:
>
> On Wed, Jun 22, 2022 at 2:26 PM Ivan Zhakov via dev
> wrote:
> >
> > Suggestions and improvements are welcome.
>
> I don't see any warning left in trunk and 1.8.x, possibly we'd have a
> Windows /Werror build
cate for the number of
captures in the regular expression (preg->re_nsub). An additional
improvement would be to cap the allocation size based on the passed-in
limit (nmatch). I'll try to handle that separately.
Thoughts?
--
Ivan Zhakov
Index: server/util_pcre.c
=
> > +
> > +return pthread_setname_np(td, name);
>
> We probably need to check for HAVE_PTHREAD_SETNAME_NP since it's _np
> (non-portable).
Thanks for the suggestion!
I'm not so familiar with autoconf stuff (that's why I created branch):
can I just check for HAVE_PTHREAD_SETNAME_NP or do I need some
autoconf magic to set it?
--
Ivan Zhakov
On Tue, 28 Jun 2022 at 00:24, Yann Ylavic wrote:
>
> Hi Ivan,
>
> On Mon, Jun 27, 2022 at 8:19 PM Ivan Zhakov wrote:
> >
> > For the longer version, let me first outline a few problems with the
> > current apr_thread_current() API:
> >
> > 1) ap
ls
when iovec count is more than WSABUF_ON_STACK, but this would break
implicit assumption that apr_socket_sendv() is atomic like writev [2].
PS: Do we have a test for such apr_socket_sendv() call?
[1] https://linux.die.net/man/2/send
[2] https://linux.die.net/man/2/writev
--
Ivan Zhakov
On Mon, 27 Jun 2022 at 21:40, Yann Ylavic wrote:
> On Mon, Jun 27, 2022 at 8:35 PM Ivan Zhakov wrote:
> >
> > On Mon, 27 Jun 2022 at 21:14, Yann Ylavic wrote:
> >>
> >> On Mon, Jun 27, 2022 at 8:08 PM Ivan Zhakov wrote:
> >> >
On Mon, 27 Jun 2022 at 21:14, Yann Ylavic wrote:
> On Mon, Jun 27, 2022 at 8:08 PM Ivan Zhakov wrote:
> >
> > On Mon, 27 Jun 2022 at 21:01, wrote:
> >>
> >> +#ifdef WIN32
> >> +typedef apr_status_t (__stdcall *encdec_fn)(char*, const char*,
>
) a try.
Thoughts?
--
Ivan Zhakov
> This uses assumptions about calling convention used on the Win32 platform.
I don't think it's a good thing. Do we really need an array of callbacks?
May just inline all these calls?
--
Ivan Zhakov
On Wed, 22 Jun 2022 at 19:26, Yann Ylavic wrote:
> On Wed, Jun 22, 2022 at 5:57 PM Ivan Zhakov wrote:
> >
> > On Wed, 22 Jun 2022 at 17:29, Yann Ylavic wrote:
> >
> >>
> >> PS: now the macos guys have some work
> >> (https://github.com/a
t 3 2 66.67%
]]]
Sometimes it works as expected:
https://github.com/apache/apr/actions/runs/2542369041
Anyone have any ideas why it may happen?
--
Ivan Zhakov
runners.
Action runners status is available on GitHub:
https://github.com/apache/apr/actions
(any GitHub account is required to see logs)
Suggestions and improvements are welcome.
--
Ivan Zhakov
On Tue, 21 Jun 2022 at 19:56, Yann Ylavic wrote:
> On Tue, Jun 21, 2022 at 6:21 PM Ivan Zhakov wrote:
> >
> > On Tue, 21 Jun 2022 at 19:16, Yann Ylavic wrote:
> >>
> >> On Tue, Jun 21, 2022 at 5:58 PM Ivan Zhakov wrote:
> >> >
> >>
===
testreslist 3 1 33.33%
]]]
Is this what are you looking for?
--
Ivan Zhakov
the below warnings
> at least currently:
>
> testfile.c:1243:13: error: ‘test_datasync_on_stream’ defined but not
> used [-Werror=unused-function]
> testfile.c:1222:13: error: ‘test_datasync_on_file’ defined but not
> used [-Werror=unused-function]
>
> Hi Yann,
No, this change is unintentional. Just incorrect conflict resolution.
Should be fixed in r1902145.
--
Ivan Zhakov
On Wed, 5 Jan 2022 at 21:37, Ivan Zhakov wrote:
> On Mon, 13 Sept 2021 at 11:57, Johan Corveleyn wrote:
> >
> > On Tue, Sep 7, 2021 at 3:58 PM Johan Corveleyn
> wrote:
> > >
> > > On Tue, Feb 23, 2021 at 9:59 AM Mariusz W wrote:
> > > >
ully not support those calls,
> conditionally, when the function
> doesn't exist on an older version of the OS.
>
> I checked, it's building fine here, did you forget to mention your
> arguments to the cmake
> invocation so we can sort this out? Which MSVC and which Windows SDK?
>
not evaluate to a function taking 0 arguments
C:\Ivan\SVN\apr\apr-1.8.x\include\arch\win32\apr_arch_misc.h(504): warning
C4033: 'apr_winapi_if_indextoname' must return a value
[6/239] Linking C executable gen_test_char.exe
ninja: build stopped: subcommand failed.
--
Ivan Zhakov
On Wed, 9 Feb 2022 at 13:47, Ivan Zhakov wrote:
> On Tue, 8 Feb 2022 at 21:58, Evgeny Kotkov
> wrote:
>
>> Ivan Zhakov writes:
>>
>> > This part is now in the following branch:
>> >
>> https://svn.ostyserver.net/svn/asf/apr/apr/branches/
On Tue, 8 Feb 2022 at 21:58, Evgeny Kotkov
wrote:
> Ivan Zhakov writes:
>
> > This part is now in the following branch:
> >
> https://svn.ostyserver.net/svn/asf/apr/apr/branches/win32-pollset-wakeup-no-file-socket-emulation
> >
> > What do you think?
> >
nd this causes specific problems for .dll loaded
> modules like our lib.
>
That's true.
But Microsoft finally fixed this in Universal CRT ( Visual Studio 2015). In
UCRT beginthreadex() is almost a wrapper around CreateThread(). So maybe it
makes sense to require VS 2015 for APR trunk and just use CreateThread?
--
Ivan Zhakov
On Thu, 20 Jan 2022 at 17:39, Ivan Zhakov wrote:
> On Fri, 14 Jan 2022 at 18:19, Ivan Zhakov wrote:
>
>> On Thu, 13 Jan 2022 at 23:37, Ruediger Pluem wrote:
>>
>>>
>>>
>>> On 1/13/22 7:04 PM, Ivan Zhakov wrote:
>>> > [[ sorry for de
On Fri, 14 Jan 2022 at 18:19, Ivan Zhakov wrote:
> On Thu, 13 Jan 2022 at 23:37, Ruediger Pluem wrote:
>
>>
>>
>> On 1/13/22 7:04 PM, Ivan Zhakov wrote:
>> > [[ sorry for delayed response ]]
>> >
>> > On Fri, 7 Jan 2022 at 17:33, Yann Ylavic
rv = apr_get_netos_error();
> -goto cleanup;
> -}
> +/* Got the right identifier, return. */
> break;
> }
> closesocket(*rd);
> @@ -438,6 +431,9 @@ apr_status_t apr_file_socket_pipe_create(apr_socke
> apr_os_sock_put(in, , p);
> apr_os_sock_put(out, , p);
>
> +/* read end of the pipe is non-blocking */
> +apr_socket_timeout_set(*in, 0);
> +
> apr_pool_cleanup_register(p, (void *)(*in), socket_pipe_cleanup,
>apr_pool_cleanup_null);
> apr_pool_cleanup_register(p, (void *)(*out), socket_pipe_cleanup,
> --
>
>
Makes sense to me. Committed in r1897245 .
Thanks!
--
Ivan Zhakov
On Thu, 13 Jan 2022 at 23:37, Ruediger Pluem wrote:
>
>
> On 1/13/22 7:04 PM, Ivan Zhakov wrote:
> > [[ sorry for delayed response ]]
> >
> > On Fri, 7 Jan 2022 at 17:33, Yann Ylavic wrote:
> >>
> >> Hi Ivan,
> >>
> >> On Fri, Jan
[[ sorry for delayed response ]]
On Fri, 7 Jan 2022 at 17:33, Yann Ylavic wrote:
>
> Hi Ivan,
>
> On Fri, Jan 7, 2022 at 2:50 PM Ivan Zhakov wrote:
> >
> > This change does not compile on Windows in APR 1.7.x:
> > [[[
> > file_io\win32\readwrite.c(3
I also have a high-level objection against backporting this change to
APR 1.7.x: IMHO APR 1.7.x is a stable branch and I think that only
regression fixes should be backported to the stable branch. r1896510
is a significant change and as far as I understand it's not a
regression fix. So I think it would be better to revert r1896510 and
release it as part of APR 2.0 (or 1.8.x).
--
Ivan Zhakov
& APR_FINFO_NAME)) {
> +if (!(wanted & (APR_FINFO_NAME | APR_FINFO_LINK))) {
> if (!GetFileAttributesExW(wfname, GetFileExInfoStandard,
>))
> return apr_get_os_error();
>
> ]]]
>
> And yes, if I revert that single hunk, the Subversion problem with
> subst'ed drives on Windows (or working copies on drive roots) is gone!
>
> Of course, I have no idea what other effects this has, but just
> confirming that taking another turn in the above conditional (like it
> was before) makes apr_stat return the same (AFAICS) as in 1.6.5, for
> substed drives or drive roots on Windows.
>
Hi,
The problem with apr_stat(APR_FINFO_LINK | APR_FINFO_MIN) should be
fixed by r1896717 [1] in trunk.
This fix also should resolve performance regression in apr_stat()
in most common cases.
I plan to backport this fix to APR 1.7.x at some point later.
Testing and review will be much appreciated! :)
[1] https://svn.apache.org/r1896717
--
Ivan Zhakov
On Thu, 2 Dec 2021 at 22:33, Mladen Turk wrote:
>
>
> On 02/12/2021 13:21, Ivan Zhakov wrote:
> > On Wed, 1 Dec 2021 at 21:26, Mladen Turk > <mailto:mt...@apache.org>> wrote:
> >
> >
> > So no uuidof used in recent Windows SDK.
> >
> &g
we have
> those in trunk/apr-2 (that will be hopefully released one day).
>
> IMHO, we should drop all that as well as windows stuff like
> APR_HAS_ANSI_FS and _WIN32_WCE (the latest one beeing my fault)
>
>
> +1.
--
Ivan Zhakov
#define IID_IXmlWriter _IID_IXmlWriter
#define IID_IXmlResolver _IID_IXmlResolver
]]
So no uuidof used in recent Windows SDK.
Btw Visual Studio 2008 support ended April 10, 2018 [1].
[1]
https://devblogs.microsoft.com/visualstudio/end-of-support-for-visual-studio-2008-in-one-year/
--
Ivan Zhakov
t; /**
> + * @deprecated @see apr_conv_utf8_to_utf16
> + */
> +#define apr_conv_utf8_to_ucs2(in, inbytes, out, outwords)
> apr_conv_utf8_to_utf16(in, inbytes, out, outwords)
>
As far as I understand this doesn't fix ABI compatibility: applications
linked with older APR cannot be used with newer one.
--
Ivan Zhakov
On Mon, 18 May 2020 at 07:42, Jan Ehrhardt wrote:
> Ivan Zhakov in gmane.comp.apache.apr.devel (Thu, 14 May 2020 12:08:26
> +0300):
> >Do we really need to keep compatibility code for operating systems
> >that are not supported for years just for a few special companies?
>
iscussed a year ago. Thread: "Supported
Windows versions for APR 2.0 (was Re: [PATCH] Optimize
apr_file_info_get(APR_FINFO_SIZE) on Windows)" [1]
[1]
https://mail-archives.apache.org/mod_mbox/apr-dev/201905.mbox/%3ccabw-3ydoqhj7iqptuej0donv4jhrlgglytzpfkckvmz+ueg...@mail.gmail.com%3e
--
Ivan Zhakov
On Wed, 13 May 2020 at 22:31, Mladen Turk wrote:
> On 13/05/2020 21:04, Ivan Zhakov wrote:
> > On Wed, 13 May 2020 at 11:41, Mladen Turk mt...@apache.org>> wrote:
> >
> > 1. Remove all those .dsp, .dsw .mak files from APR trunk
> > None of them
;
> I'm willing to solve all that since it's mainly
> cleanup of the copy/paste code that is dragging on for 10+ years
>
> [1] https://svn.apache.org/r1613114
--
Ivan Zhakov
ws."*/
> >> +return *mem;
> >
> > Where are we[1] ensuring *mem is aligned on an 8 byte boundary?
>
> Since mem is apr_uint64_t, unless the caller is playing nasty casts we
> should be good, I think.
+1.
Also InterlockedCompareExchange64() as all other interlocked function
requires aligned data [1]. So APR already assumes that data is
properly aligned.
[1]
https://docs.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-interlockedcompareexchange64
--
Ivan Zhakov
On Wed, 16 Oct 2019 at 03:15, Yann Ylavic wrote:
>
> Hi Ivan,
>
> On Tue, Oct 15, 2019 at 11:13 AM Ivan Zhakov wrote:
> >
> > On Tue, 15 Oct 2019 at 01:16, Yann Ylavic wrote:
> > >
> > > Then I don't know if we care enough about WIN32, but if so the
On Tue, 15 Oct 2019 at 01:16, Yann Ylavic wrote:
>
> On Tue, Oct 8, 2019 at 1:10 PM wrote:
> >
> > Author: ivan
> > Date: Tue Oct 8 11:10:32 2019
> > New Revision: 1868129
> >
> > URL: http://svn.apache.org/viewvc?rev=1868129=rev
> > Log:
> > apr_atomic_read64(): Fix non-atomic read on 32-bit
On Sat, 14 Sep 2019 at 16:44, Ivan Zhakov wrote:
> Hi!
>
> The apr_socket_sendfile() has Windows specific flag
> APR_SENDFILE_DISCONNECT_SOCKET. When this flag specified
> instructs Winsock to disconnect socket and prepare it for
> reuse after file send.
>
> Th
/win32/api/mswsock/nc-mswsock-lpfn_disconnectex
--
Ivan Zhakov
Index: CHANGES
===
--- CHANGES (revision 1866558)
+++ CHANGES (working copy)
@@ -224,6 +224,8 @@
*) apr_socket_listen: Allow larger listen backlog values
On Wed, 28 Aug 2019 at 10:08, Joe Orton wrote:
>
> On Sat, Aug 24, 2019 at 05:39:17PM +0300, Ivan Zhakov wrote:
> > For what it's worth, I'm -1 on the changes done in r1862071 and
> > r1862435 for the reasons listed above.
> >
> > PS: No idea if I can actually v
On Thu, 25 Jul 2019 at 15:58, Ivan Zhakov wrote:
>
> On Mon, 8 Jul 2019 at 20:05, Ivan Zhakov wrote:
> >
> > On Wed, 3 Jul 2019 at 18:37, Joe Orton wrote:
> > >
> > > On Wed, Jul 03, 2019 at 02:43:02PM +0300, Ivan Zhakov wrote:
> > > > They also m
On Mon, 8 Jul 2019 at 20:05, Ivan Zhakov wrote:
>
> On Wed, 3 Jul 2019 at 18:37, Joe Orton wrote:
> >
> > On Wed, Jul 03, 2019 at 02:43:02PM +0300, Ivan Zhakov wrote:
> > > They also make the existing old API unusable for many cases thus
> > > making a s
On Wed, 3 Jul 2019 at 18:37, Joe Orton wrote:
>
> On Wed, Jul 03, 2019 at 02:43:02PM +0300, Ivan Zhakov wrote:
> > They also make the existing old API unusable for many cases thus
> > making a switch to the new API mandatory, even though it doesn't have
> > to be so (see
On Tue, 2 Jul 2019 at 13:18, Joe Orton wrote:
>
> On Tue, Jul 02, 2019 at 09:59:20AM +0200, Branko Čibej wrote:
> > On 02.07.2019 08:49, Joe Orton wrote:
> > > On Thu, Jun 27, 2019 at 05:01:56PM +0300, Ivan Zhakov wrote:
> > >> On Tue, 25 Jun 2019 at 17:21, wro
t;
> * file_io/win32/dir.c, file_io/os2/dir.c: Likewise, but untested.
> * test/testdir.c (test_pread) [APR_POOL_DEBUG]: Add test case.
>
> I'm not sure it's best fix. Better solution would be allocate buffer for
dirname + MAX_FILE_NAME in apr_dir_t and reuse it on every iteration. Win32
already has such code.
--
Ivan Zhakov
), and I have that on my TODO
list.
Speaking of this commit, my aim here was to fix accessing the uninitialized
memory, as I did in r1860747. And this turned out to be much simpler with
the ANSI code path removed.
--
Ivan Zhakov
On Tue, 28 May 2019 at 12:17, Ruediger Pluem wrote:
> On 2019/05/28 09:12:01, Ruediger Pluem wrote:
> > On 2019/05/27 17:17:53, Ivan Zhakov wrote:
> > > On Mon, 27 May 2019 at 20:13, wrote:
> > > >
> > > > Author: ivan
> > > > Date:
s the amount of dependencies required for building and
using APR, which I believe to be a good thing in this particular case.
And it also means that by default we would be relying on the native
component of the OS rather than on a 3rd-party library.
Please let me know if there would be any objections against this change.
--
Ivan Zhakov
On Wed, 15 May 2019 at 15:25, Ivan Zhakov wrote:
>
> On Tue, 20 Dec 2016 at 10:58, Ivan Zhakov wrote:
> >
> > On 19 December 2016 at 06:45, William A Rowe Jr wrote:
> > > On Sun, Dec 18, 2016 at 11:30 AM, Ivan Zhakov wrote:
> > >>
> > >&
/Windows Server 2008 R2 is the minimum supported Windows
operating system for APR 2.0.
I've made necessary changes in CHANGES in r1859474.
--
Ivan Zhakov
On Tue, 20 Dec 2016 at 10:58, Ivan Zhakov wrote:
>
> On 19 December 2016 at 06:45, William A Rowe Jr wrote:
> > On Sun, Dec 18, 2016 at 11:30 AM, Ivan Zhakov wrote:
> >>
> >> On 17 December 2016 at 21:47, William A Rowe Jr
> >> wrote:
> >>
>
ee that it would harder to backport fixes to
stable branches. What about release apr 1.8 without ANSI logic?
--
Ivan Zhakov
lem.
>>
>> There's quite a bit more in trunk (some of it annoyingly
>> not labelled in commit messages). I've gone briefly through
>> that and see no obvious backports. Anyone else?
>
>
> There's a list of changes done by Ivan Zhakov starting with 1785072
e the behavior of the code.
>
> As these changesets were meant to be refactorings that make the code
> clearer, without altering its behavior, I think that they should be reverted
> for now.
>
> (I will prepare an alternative patch with these simplifications that doesn't
> change the behavior of the code.)
>
>
> Sorry for that,
> Evgeny Kotkov
Reverted r1806592 and r1806603 in r1806701.
--
Ivan Zhakov
On 26 August 2013 at 20:13, Stefan Ruppert <s...@myarm.com> wrote:
> Am 26.08.2013 17:48, schrieb Ivan Zhakov:
>>
>> On Mon, Aug 26, 2013 at 7:41 PM, William A. Rowe Jr.
>> <wr...@rowe-clan.net> wrote:
>>>
>>> On Mon, 26 Aug 2013 18:58:
escribed way and also includes the
> tests.
>
> The log messages are included in the beginning of each patch file.
>
> 1-file-write-simplify-local-vars-v1.patch.txt
Committed in r1806592.
> 2-file-write-simplify-fileptr-inc-v1.patch.txt
Committed in r1806603.
> 3-file-write-invert-if-condition-v1.patch.txt
Committed in r1806604.
> 4-fix-locked-append-deadlock-v1.patch.txt
Committed in r1806608.
Thanks!
--
Ivan Zhakov
efore, currently, I think that it would be better to keep this
> existing property.
>
> - Probably, implementing the first approach would result in a bit more
> complex code, as I think that it would require introducing an additional
> if-else code path.
>
> The log message is included in the beginning of the patch file.
>
Committed 3-reduce-syscalls-for-buffered-writes-v2.patch.txt patch in
r1806308. Thanks!
--
Ivan Zhakov
ing patches committed in r1806299 and r1806301.
> The third patch is the core change that implements the
> described optimization.
>
Review of core changes
(3-reduce-syscalls-for-buffered-writes-v2.patch.txt ) is in progress.
--
Ivan Zhakov
ONN_HINT()
> from an appropriate version of the SDK.
>
>
Committed in r1805309. Thanks!
--
Ivan Zhakov
trunk-only?
>
These problems fixed in APR trunk in r1788929 [1], but didn't
backported to 1.5.x and 1.6.x branches.
https://svn.apache.org/r1788929
--
Ivan Zhakov
On 28 March 2017 at 20:24, Yann Ylavic <ylavic@gmail.com> wrote:
> On Tue, Mar 28, 2017 at 2:39 PM, Ivan Zhakov <i...@visualsvn.com> wrote:
>>
>> I'm not sure that *actual* allocation size could be predicted in all
>> cases and possible apr_allocator_t impl
On 28 March 2017 at 01:02, Yann Ylavic <ylavic@gmail.com> wrote:
> On Mon, Mar 27, 2017 at 3:55 PM, Ivan Zhakov <i...@visualsvn.com> wrote:
>> On 24 March 2017 at 00:34, <yla...@apache.org> wrote:
>>> +
>>> +/**
>>> + * Return t
to align
> + * @return The aligned size (or zero on apr_size_t overflow)
> + */
> +APR_DECLARE(apr_size_t) apr_allocator_align(apr_size_t size);
What is the purpose of this API? Currently caller may use
apr_memnode_t.endp to find actually allocated memory size.
Anyway I think it maybe worth to add apr_allocator_t argument to
apr_allocator_align() function even currently allocation alignment is
the same for all allocators.
--
Ivan Zhakov
ffer after the file is truncated. Thus, reading from a file after
>apr_file_trunc() can return invalid data from the previous file offset.
>
Committed in r1788929. Thanks!
--
Ivan Zhakov
e_gets() could be further optimized by using memchr() to
find '\n' in the buffer, but I don't know whether performance
improvement worth the efforts.
https://svn.apache.org/r1785072
--
Ivan Zhakov
s to finish if thread pool callback resides
in DLL, because it could be unloaded before APR will destroy
threadpool.
--
Ivan Zhakov
s I can then leverage some SSL infra.
>>
>> Has anyone ever made an attempt to do this properly in APR ?
> It was called serf. It never entered ASF proper, but it is still out there
> (not sure if Justin moved it from Google code or not.)
>
Now it's called Apache Serf :)
http://serf.apache.org
--
Ivan Zhakov
On 27 December 2016 at 22:08, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> On Sat, Dec 24, 2016 at 1:23 AM, Ivan Zhakov <i...@visualsvn.com> wrote:
>>
>>
>> Regarding my current problem: I'm getting the following when I attempt
>> to build expat:
&
CMakeCache.txt On 24 December 2016 at 13:36, Branko Čibej
<br...@apache.org> wrote:
> On 24.12.2016 08:23, Ivan Zhakov wrote:
>>>> CMake pollutes working copy with some unrelated files.
>>>
>>> ...it does? I don't think I've had any pollution with my workflo
gt; perhaps with some support of
> alternate operating charsets for the non-httpd consumer. Would like to hear
> of folks deliberately building the ANSI flavor of APR on modern OS's and see
> if we can address any concerns.
>
--
Ivan Zhakov
the development plan for 1.7? Is going to be branched from
trunk of from 1.6.x branch? Personally I'd like to focus on APR 2.0.
--
Ivan Zhakov
On 21 December 2016 at 10:05, Jacob Champion <champio...@gmail.com> wrote:
> Ooh, this caught my eye. Mild apologies for poking my head in.
>
> On 12/20/2016 10:48 PM, Ivan Zhakov wrote:
>>
>> The problem with generators like CMake that they multiply problems in
>>
On 17 December 2016 at 10:54, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> On Sat, Dec 17, 2016 at 1:34 AM, Ivan Zhakov <i...@visualsvn.com> wrote:
>>
>> On 3 December 2016 at 18:40, William A Rowe Jr <wr...@rowe-clan.net>
>> wrote:
>> >
On 19 December 2016 at 06:45, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> On Sun, Dec 18, 2016 at 11:30 AM, Ivan Zhakov <i...@visualsvn.com> wrote:
>>
>> On 17 December 2016 at 21:47, William A Rowe Jr <wr...@rowe-clan.net>
>> wrote:
>>
>
On 12 August 2016 at 22:46, Ivan Zhakov <i...@visualsvn.com> wrote:
> Hi,
>
> Some ANSI APIs like CreateFileMappingA is not available on Windows
> Nano Server, while APR code in mmap/win32/mmap.c use
> CreateFileMappingA unconditionally. Attached patch fixes this problem.
>
rosoft.com/en-us/library/windows/desktop/ms683212(v=vs.85).aspx
[2] https://msdn.microsoft.com/en-us/subscriptions/ff723773.aspx
--
Ivan Zhakov
On 17 December 2016 at 10:56, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> On Sat, Dec 17, 2016 at 1:43 AM, Ivan Zhakov <i...@visualsvn.com> wrote:
>>
>> On 24 August 2016 at 20:34, Ivan Zhakov <i...@visualsvn.com> wrote:
>> > I was monitoring Su
1 - 100 of 134 matches
Mail list logo
