> On Mar 30, 2020, at 2:38 PM, Matthew Reddington <mredding...@pivotal.io>
> wrote:
>
>>>> Does it make sense to have the CacheFactory concept at all (especially
> since it is more of a builder)? Could we have some C struct that can be
> used to create the cache, where the struct has fields for all the
> configuration? In general can we rethink the API so that it makes sense for
> C or other language bindings?
>>> * I recommend we avoid introducing real types in the exported interface.
> In order to support future revision, we’d have to introduce version and
> size information into the struct a la THE WIN32 API. Remember that? Having
> to zero out the struct then setting the size and version members before the
> other members? This is why they did that.
>> What is this in reference to? Using structs to hold the pointers? I
> already over that solution for just using opaque struct pointers.
>
> Jake, you mentioned passing structs to initialize the cache instead of
> using a cache factory. I'm leery of introducing additional concrete types
> to yet another API. Since this isn't where we are slow, flexibility and
> future proofing are preferred. This is something the team is going to have
> to look at more options, good examples, and decide what we're willing to
> deal with long term.
Oh, yeah, that makes total sense dealing configuration structs. I am cool with
the factory/builder pattern. Its just a ton of functions. ;)
>>> * This library needs a thread safe means of error handling. There is not
> enough fleshed out in this RFC to have a meaningful conversation about this
> at this time.
>> Can you elaborate on this? If the functions all returned some error code
> what thread safety issues are you thinking about?
>
> When I think of C and error handling, I think of errno, which isn't thread
> safe. I don't want to see a repeat of that. I suppose it will boil down to
> output parameters and returning error codes.
Yeah, errno is a huge mistake.
-Jake
