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

Fixed multi instance problem on SHT3x #433 #1081

Merged
merged 1 commit into from
Mar 15, 2018
Merged

Conversation

JK-de
Copy link
Contributor

@JK-de JK-de commented Mar 14, 2018

Not tested!

It is a quick fix. Most other plugins have the same problem!!!

@psy0rz A general rework of the task structure have to be done:
Add an instance pointer to each task which is given to the plugin function like
boolean Plugin_068(byte function, struct EventStruct *event, String& string, void** inst). So you can set a class instance to any task separately

@JK-de JK-de mentioned this pull request Mar 14, 2018
@beicnet
Copy link
Contributor

beicnet commented Mar 15, 2018

@psy0rz Merge this pls! ;)

@TD-er TD-er merged commit 1abd31b into letscontrolit:mega Mar 15, 2018
TD-er added a commit to TD-er/ESPEasy that referenced this pull request Mar 15, 2018
@uzi18
Copy link
Contributor

uzi18 commented Mar 15, 2018

@TD-er maybe global void ptr[Taskmax] is solution here?
With this we constantly spend precious memory.

@TD-er
Copy link
Member

TD-er commented Mar 15, 2018

A pointer to what?
That's going to be a static_cast to what you hope is in there?
Also all plugins using this void pointer array should make sure to delete it. You cannot delete it when you don't know what object it is.
Or we should have a class ESPeasyVoid with a strict virtual destructor from which all things should inherit you want to put in there. Only then can you delete it when deleting from the web interface.

@uzi18
Copy link
Contributor

uzi18 commented Mar 15, 2018

Every task could map there own needed object, yes casting could be pain here.

@TD-er
Copy link
Member

TD-er commented Mar 15, 2018

Please make an issue for it, then we can think about it.
Might not be a bad idea, but it may have some implications I want to think about first.

@uzi18
Copy link
Contributor

uzi18 commented Mar 15, 2018

Also as You see still moving into adding to plugins dynamic allocation/deallocation of memory and not static allocated, this could produce possibility of more plugins in memory but different problems comes along.

@beicnet
Copy link
Contributor

beicnet commented Mar 17, 2018

@jkDesignDE Can you pls verify this too?

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.

4 participants