Anton Lindqvist 57af5f3c10 avoid recursive mutex acquisition in sndio backend
Ending a RTSP session while running on OpenBSD using sndio backend causes the
following crash:

	#0  thrkill ()
	#1  0x000005208224403e in _libc_abort
	#2  0x00000520821b77be in _rthread_mutex_trylock
	#3  _rthread_mutex_timedlock
	#4  0x0000051e0d54e2c0 in stop ()
	#5  0x0000051e0d544e85 in player_thread_cleanup_handler
	#6  0x0000052082243126 in _libc_pthread_exit
	#7  0x000005209a158700 in sigthr_handler
	#8  <signal handler called>
	#9  _thread_sys_poll ()
	#10 0x000005208223533e in _libc_poll_cancel
	#11 0x00000520df54c9a0 in sio_psleep
	#12 0x00000520df54cc1f in sio_write
	#13 0x0000051e0d54e27a in play
	#14 0x0000051e0d547fc0 in player_thread_func
	#15 0x000005209a158cc1 in _rthread_start
	#16 0x000005208223565a in __tfork_thread

The player thread is blocking inside sio_write() -> poll(2) while the thread is
being terminated. The stop routine tied to the same backend is invoked through
player_thread_cleanup_handler() which tries to acquire the mutex which it
already acquired before invoking sio_write(). Avoiding blocking writes would
require switching to async I/O which is quite an undertaking.

The fact that there's only one `struct sio_hdl *' instance in the compilation
unit sort of implies there can only be one player thread at a time. Therefore
fix the crash by only trying to acquire the mutex and continue as usual if it's
already acquired.
2021-12-05 09:08:01 +01:00
2021-07-15 13:42:33 +01:00
2019-11-13 22:04:22 +00:00
2020-07-06 17:09:15 +01:00
2017-01-30 23:02:07 +00:00
2021-06-04 09:40:24 +01:00
2021-09-17 19:24:10 +01:00
2017-09-07 12:02:00 +01:00
2020-07-06 17:09:15 +01:00
2020-02-20 21:32:35 +00:00
2020-07-06 17:09:15 +01:00
2020-07-06 17:09:15 +01:00
2020-07-06 17:09:15 +01:00
2021-04-01 10:12:42 -07:00
2020-07-06 17:09:15 +01:00
2020-07-06 17:09:15 +01:00
2021-04-01 10:12:42 -07:00
2014-04-30 20:47:48 +01:00
2021-10-11 19:04:33 +02:00
2021-10-24 11:28:46 +01:00
2021-07-29 13:13:01 +01:00
2014-04-30 20:47:48 +01:00
2014-10-25 14:25:21 +01:00
2021-07-07 09:02:15 +01:00
2020-02-20 21:32:35 +00:00
2020-07-06 17:09:15 +01:00
2021-07-07 09:03:20 +01:00
2017-04-16 20:04:37 +01:00
2019-11-13 22:04:22 +00:00
2017-07-31 11:57:57 +02:00
2021-09-01 16:53:14 +01:00
2021-07-19 17:10:51 +01:00
2021-07-06 22:28:15 +01:00
2020-07-06 17:09:15 +01:00
2020-07-06 17:09:15 +01:00
2021-11-01 09:18:57 +03:00
2016-03-02 17:41:33 +00:00
2014-04-30 20:47:48 +01:00
2021-07-28 16:59:35 +01:00
2021-04-26 11:30:14 +01:00
2020-06-12 09:49:27 +01:00
2021-09-29 10:08:22 +01:00
2021-05-01 14:09:38 +01:00
2021-10-24 11:36:40 +01:00
2020-07-06 17:09:15 +01:00
2021-04-26 11:35:11 +01:00

Shairport Sync

  • Shairport Sync is an AirPlay audio player – it plays audio streamed from Apple devices and from AirPlay sources such as OwnTone (formerly forked-daapd).
  • Shairport Sync can provide "classic" AirPlay 1 or limited Airplay 2 support. The AirPlay 2 build is much more demanding. It requires a faster system, more storage and more RAM both at build time and run time.
  • Shairport Sync does not support AirPlay video or photo streaming.

AirPlay 2

For the latest on AirPlay 2, please visit AIRPLAY2.md.

Guides

  • A brief guide to building classic Shairport Sync (for AirPlay 1) is available at BUILDFORAP1.md.
  • A guide to building Shairport Sync for AirPlay 2 on Linux is available at BUILDFORAP2.md.
  • A guide to building for AirPlay 2 on FreeBSD is forthcoming.

More Information

For more information, please visit MOREINFO.md.

Acknowledgements

For the development of AirPlay 2 support, special thanks are due to:

And of course, thanks to everyone who has supported and improved Shairport Sync over the years.

S
Description
No description provided
Readme
14 MiB
Languages
C 92.2%
C++ 3.7%
Shell 1.6%
M4 1.4%
Makefile 0.6%
Other 0.5%