On Wed, 8 Aug 2001, Daniel Stenberg wrote:

> On Wed, 8 Aug 2001, Sterling Hughes wrote:
>
> > This sounds like a good idea -- it should also give us a reasonable
> > performance increase over the stdio layer. One thing I am concerned
> > about is Win32 performance, but as I don't develop on that platform :)
>
> Why would we get worse performance in windows with this suggested change?
>

    I'm not sure how Win32 handles Stdio implementation as opposed to
    the POSIX layer (or if Stdio is a part of the POSIX layer). As you
    know, Win32's POSIX layer is a POS, so if it causes that switch
    (non-POSIX to POSIX), we should see a small performance hit on Win32
    systems.

> > Also, as a small implementation note, file descriptors should also be
> > wrapped in a structure, something like a curl_fd_t, just for portability
> > reasons.
>
> Why (or perhaps how)? Doesn't that just make things more complicated? I mean,
> today you just fopen() and pass in the returned pointer, why would open() and
> pass in the returned file descriptor need a different treatment?
>

    Compat with different systems, for example if we ever switch to
    native calls on win32 systems, I believe that their API's return a
    'FileDescriptor *' instead of a int, so even if you have something
    like:

    #ifndef WIN32
    typedef int curl_fd_t
    #else
    typedef FileDescriptor * curl_fd_t
    #endif

    It would help portability quite a bit.

> > Ps: Have you ever considered perhaps converting cURL over to APR, it
> > might help with issues such as this one...
>
> I have. (APR => Apache Portable Runtime for the uninitiated)
>
> The Subversion guys uses it exensively (I sometimes pretend I contribute to
> that project), and I know there's been talk about moving the neon library
> (HTTP + webdav) over to APR.
>

    :)))

> But, moving to APR for such a tiny reason seems like a huge overkill to me.
> APR is still not a standard library on machines, and it contains about 2.5
> times more source code than libcurl. It also solves issues and contains many
> functions that libcurl certainly doesn't need. I don't even think they have
> APR working in that many more platforms than we have libcurl working on.
>
> Or are there some good reasons I haven't taken into account?
>

    I think there are --

    1) APR uses native system calls, ie, Apache 2.0 on Win32 systems
    operates 50% faster. Alot of this centers around the socket api as
    well.

    2) APR is constantly in development -- Therefore newer standards,
    and new operating systems can be added to their portability layer
    without us having to change our code.

    3) I don't know how cURL handles 64 bit platforms -- with APR that's
    not a concern (well it is, but not as big a concern).

    4) Those extra functions are:

        - Shmem
        - Threads
        - DSO

    Correct? That shouldn't add too much bloat, imho.

    I'm not saying its the right solution, it very well may not be,
    because of those questions you've raised, just wondering if you had investigated
    it for cURL :)

    -Sterling

_______________________________________________
Curl-library mailing list
http://curl.haxx.se/libcurl/
Received on 2001-08-08