File: plugin-locking

package info (click to toggle)
xmms-singit 0.1.28-1
  • links: PTS
  • area: main
  • in suites: sarge
  • size: 10,188 kB
  • ctags: 8,423
  • sloc: ansic: 36,625; cpp: 33,860; sh: 8,621; makefile: 443; sed: 16
file content (32 lines) | stat: -rw-r--r-- 985 bytes parent folder | download | duplicates (2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

This file documents the SingIt engine plugin locking sheme.

There are two mutexes:
	"plugin_update_mutex" (update)
	"init_finish_mutex" (init)

and a hand of funtions:
	displayer_plugin_data_lock_init
	displayer_plugin_data_lock_init_ext
	displayer_plugin_data_unlock_init

	displayer_plugin_data_lock_plugins
	displayer_plugin_data_unlock_plugins

At the beginning "update" is locked.

The result of all lock and unlock funtion shows wether the operation has 
finished successfull. For general locking errors the plugin also produces a
error message to the console - this should never happen!!!

Every function also provides a "try_lock" parameter.

If a plugin is updated via the callback functions the callback has to try to
claim "update". "try_lock" should be set approprieted.

If function manipulate the plugin data they must claim "init" to prevent 
shutdow or initialization while performing.

There shouldn't be the need to access the locks directly.

That's the theory...