Skip to content

Conversation

@electretmike
Copy link
Contributor

operator delete(void*) was deleted. This prevented deletion of any task. I don't see a reason for that, and no need to delete the operator.

Additionally, I think a StaticTask should be able to be removed.

For context: I have a device where devices can be added to an i2c bus, and later be removed. I want to handle that on a dynamically allocated task.

Michiel van Leeuwen added 2 commits February 2, 2023 08:37
This operator does not need to be deleted. It prevents object from being
deleted after destruction. There is no use-case for that.
The only thing aboud a STaticTask is how the memory is allocated. If it
is allocated with operator new, there is no reason why it can't be
deleted. And that should kill the task.
@jonenz
Copy link
Owner

jonenz commented Feb 6, 2023

operator delete(void*) was deleted. This prevented deletion of any task. I don't see a reason for that, and no need to delete the operator.

If I remember correctly, the thought here was that since new operators were deleted, there wouldn't be any need for the delete operator. Normal classes are allocated from the heap and owned locally/on the stack, or static classes have reserved memory.

After your suggestion for adding placement new operators (#3/#6 ), I suppose that would require delete operators to be available for manually managed objects.

Additionally, I think a StaticTask should be able to be removed.

Yes, you are probably right. Out of curiosity are you trying to use placement new and delete operators to reclaim the memory, or just want the task removed from the kernel?

For context: I have a device where devices can be added to an i2c bus, and later be removed. I want to handle that on a dynamically allocated task.

Out of curiosity what does this design look like for you? For most of my projects everything is statically allocated for the lifetime of the program, so I haven't paid as much attention to these scenarios.

@jonenz
Copy link
Owner

jonenz commented Feb 6, 2023

Before merging this I think it would make sense to move the FreeRTOS "delete" functions into the base classes. Let me know if that lines up with your logic.

@electretmike
Copy link
Contributor Author

Thanks for looking into this. I am away this week, so only have accees to a phone. Apologies for slow replies!

I used placement-new an indeed tried to delete the task when it is no longer needed. This may change from spawning tasks to creating other helpers, such as timers.

The context is a device with a stm32h7 mcu. The device has connectors to which accesoires can be connected. We need 'drivers' . I would usually statically allocate everything, but in this case the hardware us nit static. And having all different drivers running at all time doesn't sound good.

@electretmike
Copy link
Contributor Author

Before merging this I think it would make sense to move the FreeRTOS "delete" functions into the base classes. Let me know if that lines up with your logic.

yes, that is what I was thinking. I'm not sure, but some classes already do it like that. At leat Task didn't.

@jonenz
Copy link
Owner

jonenz commented Feb 7, 2023

Before merging this I think it would make sense to move the FreeRTOS "delete" functions into the base classes. Let me know if that lines up with your logic.

yes, that is what I was thinking. I'm not sure, but some classes already do it like that. At leat Task didn't.

Done. I'll leave this up for you to take a look at the changes when you return. Thanks for the help!

@jonenz jonenz self-requested a review February 7, 2023 04:27
@electretmike
Copy link
Contributor Author

Those changes look good. I just didn't check the destructors of other objects before. Only Timer, which does have the destructor in the base class.

@jonenz jonenz merged commit cf91c94 into jonenz:develop Feb 13, 2023
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

Successfully merging this pull request may close these issues.

2 participants