Chuck Wolber

FWIW, I have added this to my rolling-appender (#21 ) pull request.

If you use proper locking, then yes it would be. Here is an example. ``` #include #include "log.h" pthread_mutex_t MUTEX_LOG; void log_lock(bool lock, void *udata); int main() { pthread_mutex_init(&MUTEX_LOG, NULL);...

Possibly, but locking is an extraordinarily complicated topic, and there is no one-size-fits all approach that would work with a portable library like this. For example, the above example only...

I got it working on my Macbook Pro running OS X Mavericks without any trouble. I wrote up instructions suitable for mostly non-technical people here: http://chuckwolber.blogspot.com/2014/06/downloading-garmin-fit-files-manually.html As for the error...

Update: I was able to get a stack trace almost identical to the OP when Garmin Express was running in the background. The solution is to simply shut down Garmin...

I concur that it is better for a backup to run with poor performance than to not run at all. I also agree that changing current behavior could negatively affect...

Copy that. Thank you for the clear explanation. I took a close look at the code and the `status.json` stood out to me as a curious loose-end with no obvious...

@t8m - When you say it should not be platform specific, would it be sufficient to make it an optional feature that is specific to one platform? In that way...

I have a proposed solution for this. I can submit a pull request, but I would like to hear some feedback on it first. I think this could be solved...