As noted in a previous thread regarding the values of timeouts related to the 3 major timedwait() canon implementations, I'm not exactly sure how well thought out and tested these are. Putting them in 1.6 means that people will start using them, and we could discover brokenness after the fact, and end-users will need to work around that brokenness while waiting on the next APR patch release...
My only concern is that I'm not sure if these are ready for Prime Time and if putting them in 1.6 will bite us, and any end-users who use them, in the butt. Are ANY platforms using the SysV and/or Posix versions? > On Apr 5, 2017, at 9:11 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > On Wed, Apr 5, 2017 at 6:46 AM, Jim Jagielski <j...@jagunet.com> wrote: >> >>> On Apr 5, 2017, at 6:39 AM, Yann Ylavic <ylavic....@gmail.com> wrote: >>> >>> >>> Agreed, there seems to be few (if any) alternatives, though, but: >>> avoid using apr_proc/global_mutex_timedlock() on OSX is recommended. >>> Should we make it explicit with ENOTIMPL? >>> >> >> Maybe we should reconsider the whole idea of timedlocks?? > > Without throwing them out wholesale, in the interest of other 1.6.0 > enhancements, is it reasonable to keep developing this on 2.0-dev > trunk, and back it out entirely from 1.6.x branch for now? (Not sure > if forking 1.7.x from 1.6.x and then backing out from 1.6.x is the > simplest way to make that happen, but guessing it is.) > > If the recent activity is indicative of a renewed interest in APR, either > 2.0.0 or 1.7.0 aught to follow sometime reasonable, certainly by this > time in '18, or perhaps this fall in conjunction with ACEU? > > I'd personally like to stay with niq's goal of a prompt release and > see this widely adopted long before ACUS, so we can start to dive > into what 2.0/1.7 will look like. > > >> And besides, isn't the project called Apache *Portable* Runtime? >> Back when we started it this project, the idea was that if >> Platform Foo lacked a function we "needed", APR would provide >> it, not simply willy-nilly say "Nah, ENOTIMPL!". Sure, maybe >> it wasn't the "best" implementation, but we tried. That >> whole idea was to have each system/platform have some level >> of *parity*. Have we reversed that? > > There are things that can't be implemented, but we do our best > to keep the developer above that fray. E.g. the developer does > need to be aware that Win32 doesn't fork(). But it's a decision > tree such as 'APR_HAS_FORK'? Not 'am I coding for Windows?' > > Agree that if we can implement a functionality for a missing > platform, we aught to.
