Multiple race conditions when saving files

[p-e-w]

Description of the problem or steps to reproduce

As far as I can tell, there is currently no locking at all when saving/loading files. This sets the stage for several potentially dangerous race conditions:

• If a plugin calls Buffer.Save() from an separate goroutine (e.g. a timer or a background job), this save might interleave with a user-initiated save operation, corrupting the file.

• Buffer.ReOpen() can also interleave with Buffer.Save(), loading the file in a partially written state.

• Buffer.Backup() is called asynchronously every 8 seconds (while the buffer is being modified). This means that if creating the backup takes longer than 8 seconds (e.g. slow network mount), the writes will also interleave and potentially corrupt the backup.

There might be more, this is just what I noticed from a quick look through the code.

Specifications

Commit hash: 2ef4f83
OS: Fedora 31
Terminal: GNOME Terminal

[zyedidia]

It is not possible for a plugin background job to interleave with Save because background job callbacks are run on the same thread as the main micro thread. For example when the job produces stdout, micro schedules the onStdout callback to be called on the main thread by placing the callback on the jobs channel.

In the case where the plugin spawns and manages its own goroutine (I'm not even sure if this is possible), I have just added a commit which adds a lock (micro.Lock:Lock() and micro.Lock:Unlock()) for plugins to use to make sure they don't interfere with any event handling (the lock is held by micro during all event handling code). This lock should only be used when a plugin is performing operations on the micro core in a plugin-managed thread/goroutine.