Skip to content

Conversation

@Physic69
Copy link
Contributor

No description provided.

Physic69 and others added 2 commits December 20, 2025 01:48
lunatik_obj.c Outdated
Comment on lines 61 to 62
if (!object->shared)
luaL_error(L, "%s objects cannot be shared across runtimes", object->class->name);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's not enough, right? we probably need to add single flag to the API for creating new objects..

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also, avoiding creating mutex/spinlock and refcount unnecessarily..

Comment on lines 91 to 94
union {
struct mutex mutex;
spinlock_t spin;
};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe we should have a substruct allocated dynamically for kref and lock.. but let's worry about this after having the first version settled..

#define lunatik_class_issleepable(cls) ((cls)->sleep)

#define lunatik_locker(o, mutex_op, spin_op) \
do { \
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it should check if it's single, right? it should lock in that case.. also, refcount shouldn't be applied if single

@Physic69
Copy link
Contributor Author

This version lunatik driver is working properly...
I didnt finish comments, yet.
Ill ping you once done

lunatik.h Outdated
static inline int lunatik_trylock(lunatik_object_t *object)
{
return object->sleep ? mutex_trylock(&object->mutex) : spin_trylock_bh(&object->spin);
return object->single ? 1 : lunatik_object_issleepable(object) ? mutex_trylock(&object->mutex) : spin_trylock_bh(&object->spin);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why should we return 1 if single? what's the use case?

object->gfp = sleep ? GFP_KERNEL : GFP_ATOMIC;
lunatik_newlock(object);
if(!single)
lunatik_newlock(object);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we don't need refcount as well, right?

lunatik_object_t *object = lunatik_newobject(L, &luadata_class, sizeof(luadata_t));
luadata_t *data = (luadata_t *)object->private;

object->single = single;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

doing this after the object creation won't avoid the lock init

Copy link
Contributor Author

@Physic69 Physic69 Dec 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wanted to know if im going in correct direction for creating objects:here
I didnt update the function here yet... Will do update this.. (the line is just redundancy as of now, will remove)

@Physic69
Copy link
Contributor Author

Physic69 commented Jan 2, 2026

Hi
Need some thoughts if i should continue this / use the latest externalstring function ?
IMO this might be better... externelstring is just r only. Here its luadata & its r/w.

@lneto
Copy link
Contributor

lneto commented Jan 3, 2026

Hi Need some thoughts if i should continue this / use the latest externalstring function ? IMO this might be better... externelstring is just r only. Here its luadata & its r/w.

Agreed; also, this will be useful for other objects as well, I think

@lneto
Copy link
Contributor

lneto commented Jan 6, 2026

hi @Physic69, I'm thinking that it would be better for me to tackle this issue if it's cool for you. I think I will need diff exec modes for bottom halves and irqs, I could bundle single mode on this change or at least create the flag (for implementing the decision later). Is it alright for you? Then, you could tackle another issue ;-). Thanks.

@Physic69
Copy link
Contributor Author

Physic69 commented Jan 6, 2026

hi @Physic69, I'm thinking that it would be better for me to tackle this issue if it's cool for you. I think I will need diff exec modes for bottom halves and irqs, I could bundle single mode on this change or at least create the flag (for implementing the decision later). Is it alright for you? Then, you could tackle another issue ;-). Thanks.

Sure, that’s totally fine 👍...
Thanks for taking this up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants