Skip to content
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

luajit substitute for mobdebug.coro #22

Open
johnd0e opened this issue Jun 11, 2015 · 4 comments
Open

luajit substitute for mobdebug.coro #22

johnd0e opened this issue Jun 11, 2015 · 4 comments
Assignees

Comments

@johnd0e
Copy link

johnd0e commented Jun 11, 2015

As follows from this discussion, mobdebug makes special actions to forbid debugging of that coroutines, where it was not explicitely enabled with on() call (or implicitely via coro())

It looks like overkill: forbid debugging in one place, and compensate it by unobvious and tricky coro call.

I understand that it's all for the sake of uniform module interface.

But what if you make special option for this?

@pkulchenko
Copy link
Owner

@johnd0e, you mean some special option like require('mobdebug').allowall? You don't like the fact that coro() rewrites coroutine.create? Maybe the proper solution under LuaJIT would be to still call coro(), but instead of overwriting create(), it would implement some different logic (would set an internal flag that enables debugging for all coroutines under LuaJIT)?

This would not only address your concerns/needs, but also enables coroutine debugging for those coroutines that are created with new_thread in C API. This way the Lua code is still the same (require('mobdebug').coro()), but the internal implementation is different between LuaJIT and the normal Lua code.

Thoughts?

@pkulchenko pkulchenko self-assigned this Jun 11, 2015
@johnd0e
Copy link
Author

johnd0e commented Jun 12, 2015

you mean some special option like require('mobdebug').allowall?

Exactly.

You don't like the fact that coro() rewrites coroutine.create?

I do not like it just because it is redundant entity (in the context of luajit)

Maybe the proper solution under LuaJIT would be to still call coro(), but instead of overwriting create(), it would implement some different logic

Imho this would make things even more complicated (see my concerns about coro here: #18)

This would not only address your concerns/needs, but also enables [...]

Great!

@pkulchenko
Copy link
Owner

Imho this would make things even more complicated (see my concerns about coro here: #18)

I'm confused. If we do this for LuaJIT, you wouldn't need #18 at all as the debugging would be enables without create and wrap reassigned, no?

I'd still need to track for coroutines as you may want to disable debugging with off calls for specific coroutines (and enable back with on), but it would be on by default for all LuaJIT coroutines.

@johnd0e
Copy link
Author

johnd0e commented Jun 13, 2015

If we do this for LuaJIT, you wouldn't need #18 at all

In fact I am already doing without #18 (using own coro implementation in my code).
So think of that issue as suggestion only, particularly useful for non-luajit environment.

I'd still need to track for coroutines as you may want to disable debugging with off calls for specific coroutines (and enable back with on), but it would be on by default for all LuaJIT coroutines.

Sure.
Is it possible to make on/off methods acting globally (maybe passing some argument to them)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants