| 2013-06-25 07:17:27 |
Daniel van Vugt |
bug |
|
|
added bug |
| 2013-06-25 07:34:35 |
Daniel van Vugt |
summary |
Input event callbacks are made in a different thread |
Event callbacks are made in a different thread |
|
| 2013-06-25 08:05:24 |
Daniel van Vugt |
summary |
Event callbacks are made in a different thread |
Event callbacks are not single-thread-safe |
|
| 2013-06-26 03:41:45 |
Daniel van Vugt |
mir: assignee |
|
Daniel van Vugt (vanvugt) |
|
| 2013-06-26 09:03:00 |
Daniel van Vugt |
mir: status |
New |
In Progress |
|
| 2013-06-26 11:43:43 |
Daniel van Vugt |
branch linked |
|
lp:~vanvugt/mir/fix-1194384 |
|
| 2013-06-26 12:19:35 |
Daniel van Vugt |
mir: importance |
High |
Medium |
|
| 2013-06-27 03:27:46 |
Robert Ancell |
mir: milestone |
0.0.4 |
0.0.5 |
|
| 2013-06-27 03:48:32 |
Robert Ancell |
mir: milestone |
0.0.5 |
0.0.6 |
|
| 2013-06-27 06:43:22 |
Daniel van Vugt |
summary |
Event callbacks are not single-thread-safe |
Mir client callbacks are not thread-safe |
|
| 2013-06-27 06:50:16 |
Daniel van Vugt |
description |
Input event callbacks are made in a different thread to that where they were registered (where main is running).
This is extremely dangerous.
Many toolkits and simple apps rely on having mutually exclusive callbacks. This means callbacks will always run in the same thread that the app is. If you break this guarantee then many apps and toolkits are likely to break.
If we do continue down the road of silently making single-threaded apps multi-threaded then we will need to expose locking primitives in the client API, at least. |
Mir clients may not be aware, but the callbacks made by libmirclient are not thread safe in any way.
An apparently simple single-threaded Mir client has 3 threads, which can execute concurrently:
1. The "main" thread, where the initial connection was made.
2. The socket thread, where the protocol is handled (mir_connected_callback, mir_surface_callback, MirSurfaceEvent)
3. The input thread, where input events are received (mir_event_delegate_callback)
Yes, you could receive a MirSurfaceEvent and MirMotionEvent simultaneously in different threads. Neither of which are the main thread.
This is how a Mir client works. Unfortunately the existence of these threads is not yet documented. I will update the docs. But this bug is really about finding a way to make the client API more thread safe for simple toolkits and clients that normally don't care about threads. |
|
| 2013-06-27 06:52:42 |
Daniel van Vugt |
mir: status |
In Progress |
Triaged |
|
| 2013-06-27 06:56:27 |
Daniel van Vugt |
description |
Mir clients may not be aware, but the callbacks made by libmirclient are not thread safe in any way.
An apparently simple single-threaded Mir client has 3 threads, which can execute concurrently:
1. The "main" thread, where the initial connection was made.
2. The socket thread, where the protocol is handled (mir_connected_callback, mir_surface_callback, MirSurfaceEvent)
3. The input thread, where input events are received (mir_event_delegate_callback)
Yes, you could receive a MirSurfaceEvent and MirMotionEvent simultaneously in different threads. Neither of which are the main thread.
This is how a Mir client works. Unfortunately the existence of these threads is not yet documented. I will update the docs. But this bug is really about finding a way to make the client API more thread safe for simple toolkits and clients that normally don't care about threads. |
Mir clients may not be aware, but the callbacks made by libmirclient are not thread safe in any way.
An apparently simple single-threaded Mir client has 3 threads, which can execute concurrently:
1. The "main" thread, where the initial connection was made.
2. The socket thread, where the protocol is handled (mir_connected_callback, mir_surface_callback, MirSurfaceEvent)
3. The input thread, where input events are received (mir_event_delegate_callback)
Yes, you could receive a MirSurfaceEvent and MirMotionEvent simultaneously in different threads. Neither of which are the main thread.
This is how a Mir client works. Unfortunately the existence of these threads is not yet documented. I will update the docs. But this bug is really about finding a way to make the client API more thread safe for simple toolkits and clients that normally don't care about threads.
To make matters worse, the client API functions are generally not thread safe either: mir_surface_* mir_connection_*. So libmirclient forces you to run in multiple threads and yet doesn't protect you at all against races and corruption that could arise from calling libmirclient from varying threads. |
|
| 2013-06-27 06:59:48 |
Daniel van Vugt |
description |
Mir clients may not be aware, but the callbacks made by libmirclient are not thread safe in any way.
An apparently simple single-threaded Mir client has 3 threads, which can execute concurrently:
1. The "main" thread, where the initial connection was made.
2. The socket thread, where the protocol is handled (mir_connected_callback, mir_surface_callback, MirSurfaceEvent)
3. The input thread, where input events are received (mir_event_delegate_callback)
Yes, you could receive a MirSurfaceEvent and MirMotionEvent simultaneously in different threads. Neither of which are the main thread.
This is how a Mir client works. Unfortunately the existence of these threads is not yet documented. I will update the docs. But this bug is really about finding a way to make the client API more thread safe for simple toolkits and clients that normally don't care about threads.
To make matters worse, the client API functions are generally not thread safe either: mir_surface_* mir_connection_*. So libmirclient forces you to run in multiple threads and yet doesn't protect you at all against races and corruption that could arise from calling libmirclient from varying threads. |
Mir clients may not be aware, but the callbacks made by libmirclient are not thread safe in any way.
An apparently simple single-threaded Mir client has 3 threads, which can execute concurrently:
1. The "main" thread, where the initial connection was made.
2. The socket thread, where the protocol is handled (mir_connected_callback, mir_surface_callback, MirSurfaceEvent)
3. The input thread, where input events are received (MirMotionEvent, MirKeyEvent)
Yes, you could receive a MirSurfaceEvent and MirMotionEvent simultaneously in different threads. Neither of which are the main thread.
This is how a Mir client works. Unfortunately the existence of these threads is not yet documented. I will update the docs. But this bug is really about finding a way to make the client API more thread safe for simple toolkits and clients that normally don't care about threads.
To make matters worse, the client API functions are generally not thread safe either: mir_surface_* mir_connection_*. So libmirclient forces you to run in multiple threads and yet doesn't protect you at all against races and corruption that could arise from calling libmirclient from varying threads. |
|
| 2013-06-27 07:01:06 |
Daniel van Vugt |
tags |
|
clientapi |
|
| 2013-06-27 08:06:10 |
Daniel van Vugt |
mir: status |
Triaged |
In Progress |
|
| 2013-07-01 08:21:02 |
Daniel van Vugt |
description |
Mir clients may not be aware, but the callbacks made by libmirclient are not thread safe in any way.
An apparently simple single-threaded Mir client has 3 threads, which can execute concurrently:
1. The "main" thread, where the initial connection was made.
2. The socket thread, where the protocol is handled (mir_connected_callback, mir_surface_callback, MirSurfaceEvent)
3. The input thread, where input events are received (MirMotionEvent, MirKeyEvent)
Yes, you could receive a MirSurfaceEvent and MirMotionEvent simultaneously in different threads. Neither of which are the main thread.
This is how a Mir client works. Unfortunately the existence of these threads is not yet documented. I will update the docs. But this bug is really about finding a way to make the client API more thread safe for simple toolkits and clients that normally don't care about threads.
To make matters worse, the client API functions are generally not thread safe either: mir_surface_* mir_connection_*. So libmirclient forces you to run in multiple threads and yet doesn't protect you at all against races and corruption that could arise from calling libmirclient from varying threads. |
Mir clients may not be aware, but the callbacks made by libmirclient are not thread safe in any way.
An apparently simple single-threaded Mir client has 3 threads, which can execute concurrently:
1. The "main" thread, where the initial connection was made.
2. The socket thread, where the protocol is handled (mir_connected_callback, mir_surface_callback, MirSurfaceEvent)
3. The input thread, where input events are received (MirMotionEvent, MirKeyEvent)
Yes, you could receive a MirSurfaceEvent and MirMotionEvent simultaneously in different threads. Neither of which are the main thread.
This is how a Mir client works. Unfortunately the existence of these threads is not yet documented. I will update the docs. But this bug is really about finding a way to make the client API more thread safe for simple toolkits and clients that normally don't care about threads.
To make matters worse, the client API functions are generally not thread safe either: mir_surface_* mir_connection_*. So libmirclient forces you to run in multiple threads and yet doesn't protect you at all against races and corruption that could arise from calling libmirclient from varying threads.
UPDATE: See lp:~vanvugt/mir/threadsafe-clients |
|
| 2013-07-01 08:21:24 |
Daniel van Vugt |
branch linked |
|
lp:~vanvugt/mir/threadsafe-clients |
|
| 2013-07-01 08:22:41 |
Daniel van Vugt |
description |
Mir clients may not be aware, but the callbacks made by libmirclient are not thread safe in any way.
An apparently simple single-threaded Mir client has 3 threads, which can execute concurrently:
1. The "main" thread, where the initial connection was made.
2. The socket thread, where the protocol is handled (mir_connected_callback, mir_surface_callback, MirSurfaceEvent)
3. The input thread, where input events are received (MirMotionEvent, MirKeyEvent)
Yes, you could receive a MirSurfaceEvent and MirMotionEvent simultaneously in different threads. Neither of which are the main thread.
This is how a Mir client works. Unfortunately the existence of these threads is not yet documented. I will update the docs. But this bug is really about finding a way to make the client API more thread safe for simple toolkits and clients that normally don't care about threads.
To make matters worse, the client API functions are generally not thread safe either: mir_surface_* mir_connection_*. So libmirclient forces you to run in multiple threads and yet doesn't protect you at all against races and corruption that could arise from calling libmirclient from varying threads.
UPDATE: See lp:~vanvugt/mir/threadsafe-clients |
Mir clients may not be aware, but the callbacks made by libmirclient are not thread safe in any way.
An apparently simple single-threaded Mir client has 3 threads, which can execute concurrently:
1. The "main" thread, where the initial connection was made.
2. The socket thread, where the protocol is handled (mir_connected_callback, mir_surface_callback, MirSurfaceEvent)
3. The input thread, where input events are received (MirMotionEvent, MirKeyEvent)
Yes, you could receive a MirSurfaceEvent and MirMotionEvent simultaneously in different threads. Neither of which are the main thread.
This is how a Mir client works. Unfortunately the existence of these threads is not yet documented. I will update the docs. But this bug is really about finding a way to make the client API more thread safe for simple toolkits and clients that normally don't care about threads.
UPDATE: Client API docs improved in r789.
To make matters worse, the client API functions are generally not thread safe either: mir_surface_* mir_connection_*. So libmirclient forces you to run in multiple threads and yet doesn't protect you at all against races and corruption that could arise from calling libmirclient from varying threads.
UPDATE: See lp:~vanvugt/mir/threadsafe-clients |
|
| 2013-07-01 08:23:06 |
Daniel van Vugt |
mir: status |
In Progress |
Triaged |
|
| 2013-07-01 08:23:52 |
Daniel van Vugt |
branch unlinked |
lp:~vanvugt/mir/threadsafe-clients |
|
|
| 2013-07-08 03:05:27 |
Robert Ancell |
mir: milestone |
0.0.6 |
0.0.7 |
|
| 2013-07-14 20:59:40 |
Robert Ancell |
mir: milestone |
0.0.7 |
|
|
| 2013-07-14 20:59:43 |
Robert Ancell |
mir: milestone |
|
0.0.8 |
|
| 2013-07-21 21:52:29 |
Robert Ancell |
mir: milestone |
0.0.8 |
0.0.9 |
|
| 2013-07-22 01:51:20 |
Daniel van Vugt |
description |
Mir clients may not be aware, but the callbacks made by libmirclient are not thread safe in any way.
An apparently simple single-threaded Mir client has 3 threads, which can execute concurrently:
1. The "main" thread, where the initial connection was made.
2. The socket thread, where the protocol is handled (mir_connected_callback, mir_surface_callback, MirSurfaceEvent)
3. The input thread, where input events are received (MirMotionEvent, MirKeyEvent)
Yes, you could receive a MirSurfaceEvent and MirMotionEvent simultaneously in different threads. Neither of which are the main thread.
This is how a Mir client works. Unfortunately the existence of these threads is not yet documented. I will update the docs. But this bug is really about finding a way to make the client API more thread safe for simple toolkits and clients that normally don't care about threads.
UPDATE: Client API docs improved in r789.
To make matters worse, the client API functions are generally not thread safe either: mir_surface_* mir_connection_*. So libmirclient forces you to run in multiple threads and yet doesn't protect you at all against races and corruption that could arise from calling libmirclient from varying threads.
UPDATE: See lp:~vanvugt/mir/threadsafe-clients |
Mir clients may not be aware, but the callbacks made by libmirclient are not thread safe in any way.
An apparently simple single-threaded Mir client has 3 threads, which can execute concurrently:
1. The "main" thread, where the initial connection was made.
2. The socket thread, where the protocol is handled (mir_connected_callback, mir_surface_callback, MirSurfaceEvent)
3. The input thread, where input events are received (MirMotionEvent, MirKeyEvent)
Yes, you could receive a MirSurfaceEvent and MirMotionEvent simultaneously in different threads. Neither of which are the main thread.
This is how a Mir client works. Unfortunately the existence of these threads is not yet documented. I will update the docs. But this bug is really about finding a way to make the client API more thread safe for simple toolkits and clients that normally don't care about threads.
UPDATE: Client API docs improved in r789.
To make matters worse, the client API functions are generally not thread safe either: mir_surface_* mir_connection_*. So libmirclient forces you to run in multiple threads and yet doesn't protect you at all against races and corruption that could arise from calling libmirclient from varying threads.
UPDATE: Fixed in r827 |
|
| 2013-07-22 01:51:42 |
Daniel van Vugt |
description |
Mir clients may not be aware, but the callbacks made by libmirclient are not thread safe in any way.
An apparently simple single-threaded Mir client has 3 threads, which can execute concurrently:
1. The "main" thread, where the initial connection was made.
2. The socket thread, where the protocol is handled (mir_connected_callback, mir_surface_callback, MirSurfaceEvent)
3. The input thread, where input events are received (MirMotionEvent, MirKeyEvent)
Yes, you could receive a MirSurfaceEvent and MirMotionEvent simultaneously in different threads. Neither of which are the main thread.
This is how a Mir client works. Unfortunately the existence of these threads is not yet documented. I will update the docs. But this bug is really about finding a way to make the client API more thread safe for simple toolkits and clients that normally don't care about threads.
UPDATE: Client API docs improved in r789.
To make matters worse, the client API functions are generally not thread safe either: mir_surface_* mir_connection_*. So libmirclient forces you to run in multiple threads and yet doesn't protect you at all against races and corruption that could arise from calling libmirclient from varying threads.
UPDATE: Fixed in r827 |
Mir clients may not be aware, but the callbacks made by libmirclient are not thread safe in any way.
An apparently simple single-threaded Mir client has 3 threads, which can execute concurrently:
1. The "main" thread, where the initial connection was made.
2. The socket thread, where the protocol is handled (mir_connected_callback, mir_surface_callback, MirSurfaceEvent)
3. The input thread, where input events are received (MirMotionEvent, MirKeyEvent)
Yes, you could receive a MirSurfaceEvent and MirMotionEvent simultaneously in different threads. Neither of which are the main thread.
This is how a Mir client works. Unfortunately the existence of these threads is not yet documented. I will update the docs. But this bug is really about finding a way to make the client API more thread safe for simple toolkits and clients that normally don't care about threads. UPDATE: Client API docs improved in r789.
To make matters worse, the client API functions are generally not thread safe either: mir_surface_* mir_connection_*. So libmirclient forces you to run in multiple threads and yet doesn't protect you at all against races and corruption that could arise from calling libmirclient from varying threads. UPDATE: Fixed in r827 |
|
| 2013-07-22 01:52:05 |
Daniel van Vugt |
mir: assignee |
Daniel van Vugt (vanvugt) |
|
|
| 2013-08-11 21:21:36 |
Robert Ancell |
mir: milestone |
0.0.9 |
0.0.10 |
|
| 2013-08-26 00:12:51 |
Robert Ancell |
mir: milestone |
0.0.10 |
0.0.11 |
|
| 2013-09-27 19:52:41 |
kevin gunn |
mir: importance |
Medium |
High |
|
| 2013-09-30 06:06:31 |
Daniel van Vugt |
mir: milestone |
0.0.11 |
0.0.13 |
|
| 2013-10-03 21:10:03 |
Chris Gagnon |
tags |
clientapi |
clientapi qa-touch |
|
| 2013-10-10 05:42:52 |
Daniel van Vugt |
mir: milestone |
0.0.13 |
|
|
| 2013-11-21 06:08:20 |
Daniel van Vugt |
mir: assignee |
|
Daniel van Vugt (vanvugt) |
|
| 2013-11-21 07:02:06 |
Daniel van Vugt |
mir: status |
Triaged |
In Progress |
|
| 2013-11-21 07:02:08 |
Daniel van Vugt |
mir: milestone |
|
0.1.2 |
|
| 2013-11-25 03:10:48 |
Daniel van Vugt |
mir: milestone |
0.1.2 |
0.1.3 |
|
| 2013-11-27 08:32:12 |
Daniel van Vugt |
branch linked |
|
lp:~vanvugt/mir/event-queue |
|
| 2013-12-12 02:48:01 |
Daniel van Vugt |
mir: status |
In Progress |
Triaged |
|
| 2013-12-12 02:48:05 |
Daniel van Vugt |
mir: milestone |
0.1.3 |
|
|
| 2014-01-03 01:38:20 |
Daniel van Vugt |
tags |
clientapi qa-touch |
clientapi input qa-touch |
|
| 2014-02-21 01:33:59 |
Daniel van Vugt |
mir: assignee |
Daniel van Vugt (vanvugt) |
|
|
| 2014-02-26 16:45:09 |
kevin gunn |
mir: importance |
High |
Critical |
|
| 2014-05-29 09:54:11 |
Allison Karlitskaya |
bug |
|
|
added subscriber Ryan Lortie |
| 2014-07-22 01:56:10 |
Daniel van Vugt |
mir: importance |
Critical |
High |
|
| 2014-10-28 08:04:26 |
Xu Bin |
bug |
|
|
added subscriber Xu Bin |
| 2015-02-24 09:09:40 |
Maarten Lankhorst |
bug task added |
|
xmir |
|
| 2015-02-24 09:09:50 |
Maarten Lankhorst |
xmir: status |
New |
Confirmed |
|
| 2015-02-24 09:09:52 |
Maarten Lankhorst |
xmir: importance |
Undecided |
Wishlist |
|
| 2015-06-09 04:36:35 |
Robert Ancell |
affects |
xmir |
xorg-server (Ubuntu) |
|
| 2015-06-09 04:37:15 |
Robert Ancell |
tags |
clientapi input qa-touch |
clientapi input qa-touch xmir |
|
| 2015-09-09 00:34:06 |
Robert Ancell |
bug task deleted |
xorg-server (Ubuntu) |
|
|
| 2015-10-05 03:59:31 |
Daniel van Vugt |
mir: importance |
High |
Medium |
|
| 2017-11-03 15:25:21 |
Michał Sawicz |
mir (Ubuntu): importance |
Undecided |
Medium |
|
| 2017-11-03 15:25:21 |
Michał Sawicz |
mir (Ubuntu): status |
New |
Triaged |
|
