api: cffi api to create account manager with existing events channel to see events emitted during startup. dc_event_channel_new, dc_event_channel_unref, dc_event_channel_get_event_emitter and dc_accounts_new_with_event_channel
#7609
Conversation
see events emitted during startup. `dc_event_channel_new`, `dc_event_channel_unref`, `dc_event_channel_get_event_emitter` and `dc_accounts_new_with_event_channel`
| * Note: Use only one event emitter per account manager. | ||
| * Having more than one event emitter running at the same time on the same account manager | ||
| * will result in events randomly delivered to the one or to the other. |
There was a problem hiding this comment.
Is this still the case?, rust code looks like it allows multiple listeners: it uses and async broadcast.
There was a problem hiding this comment.
Looks like it, probably it was forgotten in #5478 to update the documentation. But of course, the only way to be totally sure is actually trying it out.
| } | ||
| } | ||
|
|
||
| pub type dc_event_channel_t = Cell<Option<Events>>; |
There was a problem hiding this comment.
Cell is not thread-safe. If C side uses this from multiple threads, this can result in memory corruption when trying to write into the same Option multiple times. Better use Arc<Mutex<Option<Events>>> so it is not possible to create two account managers by initializing them at the same time.
There was a problem hiding this comment.
I.e. Mutex instead of Cell and Arc instead of Box below. OTOH do we need thread safety here? We can just document that it's not thread-safe. By using Mutex we only add thread safety to the buggy scenario which shouldn't happen anyway.
There was a problem hiding this comment.
OTOH do we need thread safety here? We can just document that it's not thread-safe.
All CFFI API is declared as thread-safe so we don't have to think about which is safe and which is not:
core/deltachat-ffi/deltachat.h
Lines 143 to 147 in fd90493
It's probably not really true that all code is thread-safe because we don't have Mutexes around Message object, but that's a bug in that code, let's not add more bugs.
| eprintln!("ignoring careless call to dc_event_channel_unref()"); | ||
| return; | ||
| } | ||
| let _ = Box::from_raw(event_channel); |
There was a problem hiding this comment.
We write this as drop(Box::from_raw(event_channel)) everywhere else.
There was a problem hiding this comment.
yeah that's clearer, though "everywhere" is not quite correct, at-least not from the place I copied this from. could be a follow up pr to make sure it is the same everywhere, though I'm not sure how important it is for the existing calls.
|
|
||
| /** | ||
| * Create a new account manager with an existing events channel, | ||
| * which allows you see events emitted during startup. |
There was a problem hiding this comment.
| * which allows you see events emitted during startup. | |
| * which allows you to see events emitted during startup. |
| * Create a new account manager with an existing events channel, | ||
| * which allows you see events emitted during startup. | ||
| * | ||
| * The account manager takes an directory |
There was a problem hiding this comment.
| * The account manager takes an directory | |
| * The account manager takes a directory |
Maybe it's better not to duplicate the documentation, but just add a reference to dc_account_new() and explain the difference. Otherwise API users need to read both and build a diff in their head, and we have more text to maintain.
| } | ||
| } | ||
|
|
||
| pub type dc_event_channel_t = Cell<Option<Events>>; |
There was a problem hiding this comment.
I.e. Mutex instead of Cell and Arc instead of Box below. OTOH do we need thread safety here? We can just document that it's not thread-safe. By using Mutex we only add thread safety to the buggy scenario which shouldn't happen anyway.
closes #7606