-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Integrate js-contexts
and js-async-cancellable
#21
Comments
js-async-cancellable
and return PromiseCancellable
js-async-cancellable
and return PromiseCancellable
and take @cancellable
and @timed
contexts
This will require the But being able to take context decorators will be difficult, as that relies on a shared weakmap. Was investigating how to do this in a way where different libraries can work. That is where This could be done by having a "factory" function produce the But what about the That would mean both |
The One issue is the existence of Anyway, it seems that it would require a However it's also possible that the decorators aren't appropriate pattern to use here. The reason is:
So basically:
const pC = lock.waitForUnlock({ timer, signal })
pC.cancel();
const pC = lock.waitForUnlock({ timer: new Timer(100) })
pC.cancel();
const pC = lock.waitForUnlock({ timer: 100 })
pC.cancel();
const pC = lock.waitForUnlock(100)
pC.cancel(); The Finally So it's fairly large change set to deal with this. Also should we also handle raw numbers for the timer as a quick way of specifying that you want a new timer? I think these 2 are equivalent.
|
@tegefaulkes the issue here is what is relevant specifies how we should deal with locking and abortion signals. In the future, it will be easy enough to just do |
For our own usage, the easiest thing would to be have just Right now I need the |
The repo is now available: https://github.com/MatrixAI/js-contexts. We won't bother with putting context functions into these repos. However this issue is still alive because the locking functions should be able to take the |
Any development of the Basically deadlock detection should be developed in consideration of all these libraries:
The Eventually we would have a pretty good DSL for expressing all sorts of concurrent operations. Note that locking implies pessimistic concurrency control. Another alternative is just to try and rollback... that's what we have in |
js-async-cancellable
and return PromiseCancellable
and take @cancellable
and @timed
contextsjs-contexts
and js-async-cancellable
See this comment MatrixAI/js-quic#26 (comment). It implies that if we were to add class X {
public f(ctx?: ContextLocked): Promise<void>;
@locked()
public async f(@context ctx: ContextLocked): Promise<void> {
await ctx.locks.lock('some key');
}
} There is some difference though. But the However if you added parameters to the class X {
public f(ctx?: ContextLocked): Promise<void>;
@locked('some key')
public async f(@context ctx: ContextLocked): Promise<void> {
// Locking the same key, so it's re-entrant, it's fine
await ctx.locks.lock('some key');
}
} Furthermore, we would want to just use One could say that Furthermore since it's a lockbox, we can pass a But if we specialise to class X {
public f(ctx?: ContextLocked): Promise<void>;
@locked('some key', 1230)
public async f(@context ctx: ContextLocked): Promise<void> {
// Locking the same key, so it's re-entrant, it's fine
await ctx.locks.lock('some key');
}
} If we do such a thing, then |
Of course another question is how does Do you end up propagating anything in the
I think it makes sense to be automatically used. Thus any |
Therefore Perhaps More appropriately called At the same time, such a thing Basically this would mean factoring out the re-entrancy and future-possible deadlock detection into a
There was some limitation in signature ambiguity... but it can probably be resolved. |
Anyway that means Also we cannot use So in this case, we just need repeat some code... |
As explained here MatrixAI/js-quic#26 (comment). It's not sufficient to just create a new lock, because there's no shared context between the locks. This then relies on the shared context that exists in this decorator system. The problem is that there has to be a "shared" point of synchronisation between different decorators. In the case of I think the idea was to avoid needing to use a class decorator to provide that shared point... but then, maybe that's not such a bad idea. We could use a There would then be Actually I realise that I actually solved the above problem already with the I just need to expand the weak map with This then obviates the need to have a class decorator. Which is far more elegant. Then a shared lock can be made possible on the target... by using the same weakmap, the first very first call using This is crazy metaprogramming, but it would end up being pretty cool. |
Ok it's a bit complicated than that. Going back over
Therefore we could use the Then for each In protected _locks: Map<
string,
{
lock: RWLockWriter;
type: 'read' | 'write';
release: ResourceRelease;
}
> = new Map(); |
There was a discussion about re-entrancy. Suppose you had: class X {
f(ctx?: Partial<ContextMonitored & ContextTimed>): Promise<void>;
@monitored()
async f(@context ctx: ContextMonitored & ContextTimed) {
await ctx.monitor.lock('a', 'b');
await this.g(ctx);
}
g(ctx?: Partial<ContextMonitored>): Promise<void>;
@monitored()
async g(@context ctx: ContextMonitored) {
await ctx.monitor.lock('b', 'a');
}
}
const x = new X();
const ctx = createCtx();
await Promise.all([
x.f(ctx),
x.g(ctx),
]); Suppose the Of course the solution to recover mutual exclusion in that scenario is to add an additional key, that being of Note that even if we didn't lock Remember locks are always "lower level" constructs compared to SI/SSI. |
Released as 4.0.0. Published 4.0.0 of js-async-locks, this brings in Monitor, and the the ability to use ctx ,most things should work as normal, but there may be slight timing issues if there's code that relies on it, we will be testing integration of 4.0.0 for js-async-locks and updating to 1.1.1 for any usage js-timer. Much more difficult than expected to get all this into the system, but now it's ready to be used by all downstream systems including |
Specification
Locking functions that have a possibility of being deadlocked should be able to take
ContextTimed
contexts. Like:await lock.waitForUnlock(ctx);
.Where
ctx: { timer, signal }
.This is where we can apply our context decorators like
@timed
and@cancellable
.This will be a major breaking API, but most users won't need to adjust, since they are not even using the timeout parameter atm.
Additional context
signalPromise
utility when doing aPromise.race
with the underlyingasync-mutex
Tasks
The text was updated successfully, but these errors were encountered: