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.
