SLB 'devkit' ?

GFA, ASM, STOS, ...

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

ThorstenOtto
Atari Super Hero
Atari Super Hero
Posts: 815
Joined: Sun Aug 03, 2014 5:54 pm

Re: SLB 'devkit' ?

Postby ThorstenOtto » Fri Sep 13, 2019 10:06 pm

JeanMars wrote:has to know SLB dependencies regarding the modules


It doesn't have to know, it just has to provide the interface. I think that's better than reimplementing pnglib, tiff and jpeg lib as it is currently the case.

even reimplement qsort and bsearch primitives


That's just a detail. For zview that was not a problem because i could just use the library function. But if that really matters i can also move them to the modules that need them.

That's why for the time being I'll stick Vision to the LDG model.


Thats your choice of course, but IIRC it was you who asked for SLB support, long before i started working on zview and the modules.

JeanMars
Captain Atari
Captain Atari
Posts: 177
Joined: Fri Apr 09, 2010 5:15 pm
Location: France
Contact:

Re: SLB 'devkit' ?

Postby JeanMars » Fri Sep 13, 2019 11:03 pm

Hi Thorsten,

Thats your choice of course, but IIRC it was you who asked for SLB support, long before i started working on zview and the modules.

Originally, it was to provide support for png to Vision, this has been done by using the SLB png library (the port you made for Atari from open source library). Here it makes sense for the app to know this dependency as I had to understand how to implement the png interface exposed by the lib to Vision.
But when it comes to go through an image plugin abstraction layer using SLB, I personally don't expect the app to be aware of any dependency such as zlib, it should be up to the plugin to deal with that.
I understand that it is not possible/easy at all with this design to mask this dependency to the app, but thats why I'm relunctant to go with.

I think (but I may be wrong) that you end up with this "app provides support for std functions/slb entry points" because the memory wasted by duplicating same portions of code from the plugins was simply too much. But as I said, another approach here is to load the plugin only when required and if necessary a smart plugin unload mecanism can help.

BTW, I've just noted that when unloading a LDG, the memory does not return back to the OS:
14/09/19 00:57:32 [INFO] Need to unload modules as estimate is 692870 KB and stram/ttram available is 13848/222392
14/09/19 00:57:32 [INFO] Request to unload some image module(s)...
14/09/19 00:57:32 [IMG] Unloading ZVLDG #11 H:\pure_c\projects\vision\zcodecs\codecs\ANIMASTR.LDG (used 24 times)
...tons of such unloads....
14/09/19 00:57:32 [IMG] Unloading ZVLDG #65 H:\pure_c\projects\vision\zcodecs\codecs\NEOANI.LDG (used 2 times)
14/09/19 00:57:32 [INFO] Need to unload modules as estimate is 692870 KB and stram/ttram available is 13848/222392
14/09/19 00:57:32 [INFO] 81 modules unloaded

At the end, the memory available did not change!
Is there a bug in ldg_term function?

ThorstenOtto
Atari Super Hero
Atari Super Hero
Posts: 815
Joined: Sun Aug 03, 2014 5:54 pm

Re: SLB 'devkit' ?

Postby ThorstenOtto » Sat Sep 14, 2019 7:35 am

JeanMars wrote:it should be up to the plugin to deal with that.


If that had been possible i would have implemented that.

if necessary a smart plugin unload mecanism can help.


How can the app implement a smart unload if it does not know about the dependencies? zlib for example is used by several modules. For that to work, the app needs at least to maintain some kind of reference counter. And that can also only been done by the app since the modules don't know about each other.

Is there a bug in ldg_term function?


I don't know, maybe it is not unloaded immediately. And have you ldg.prg in the auto folder? And how to you display the available mem, if you just display the largest block, it might just have been fragmented.

AnthonyJ
Atari freak
Atari freak
Posts: 67
Joined: Sat Jan 26, 2013 8:16 am

Re: SLB 'devkit' ?

Postby AnthonyJ » Sat Sep 14, 2019 8:45 am

For that to work, the app needs at least to maintain some kind of reference counter. And that can also only been done by the app since the modules don't know about each other.

I haven’t looked at any of the code / current design so could be completely wrong, but perhaps a potential solution to break this assumption?

Could the modules know about each other? Or perhaps more precisely, the modules themselves reference counting users? So a zlib SLB can be loaded by each SLB that needs it, and the zlib SLB won’t be released until it has 0 user?

Apparent leak on releasing LDG could be Malloc vs malloc?

JeanMars
Captain Atari
Captain Atari
Posts: 177
Joined: Fri Apr 09, 2010 5:15 pm
Location: France
Contact:

Re: SLB 'devkit' ?

Postby JeanMars » Sat Sep 14, 2019 4:57 pm

Hi,

maybe it is not unloaded immediately. And have you ldg.prg in the auto folder? And how to you display the available mem, if you just display the largest block, it might just have been fragmented.

I tried with ldg.prg in auto folder, same behavior.
I'm using Mxalloc(-1, 0) and Mxalloc(-1, 1) to get available ST & TT RAM (Malloc(-1) on old systems). Not sure if it is full memory or largest block. Does somebody know how to get full memory available?

Is there any tool which can display in "real time" the amount of ST/TT RAM available ?

How can the app implement a smart unload if it does not know about the dependencies? zlib for example is used by several modules. For that to work, the app needs at least to maintain some kind of reference counter. And that can also only been done by the app since the modules don't know about each other.

Interesting point. I would expect SLB open/close functions to take care of that. slb_open/slb_close should maintain some global counter on the number of times this lib is referenced. When this counter gets to 0 on slb_close, code memory should be freed.
Let's take an example:
app loads png sbl which loads zlib SLB.
app loads jpg slb which loads zlib SLB.
At this point, there is: 1 instance in memory of png, jpg and zlib code, usage_counter(png)=1, usage_counter(jpg)=1, usage_counter(zlib)=2
app unloads png slb:
png slb unloads zlib SLB, so usage_counter(zlib)=1, it stays in memory, usage_counter(png)=0, it is released from memory
app unloads jpg slb:
jpg slb unloads zlib SLB, so usage_counter(zlib)=0, it is released from memory, usage_counter(png)=0, it is released from memory

Of course this counter mecanism is shared across all applications as we are in a mutitasking environment.

That is how I would expect SLB to work, but I may be wrong. If so, maybe it's time to enhance this dynamic modules design instead of pushing that management to apps.

Thorsten, on zvSLB plugin model, app provides slb_open/close callbacks to plugin because it saves memory/helps plugin dev or because there is no other choice: plugin has to get back to app for SLB loading? What would happen if plugin loads SLB directly without using this app callback?

ThorstenOtto
Atari Super Hero
Atari Super Hero
Posts: 815
Joined: Sun Aug 03, 2014 5:54 pm

Re: SLB 'devkit' ?

Postby ThorstenOtto » Sat Sep 14, 2019 5:58 pm

JeanMars wrote:Not sure if it is full memory or largest block. Does somebody know how to get full memory available?


Malloc(-1) only gives you the size of the largest block, that might be the same if the module was loaded somewhere else. To get the total memory, you can use Dfree(35) on Mint. For Single-TOS, you have to allocate blocks until you get NULL, then free them again. In ORCS, i use something like this:

Code: Select all

size_t mem_available(void)
{
   DISKINFO d;
   
   size_t coresize;
   size_t thissize;
   void **buf;
   void **list;

   /* this is like fsstat(u:/proc) */
   if (Dfree(&d, 35) >= 0)
      return d.b_free * d.b_secsiz * d.b_clsiz;
   
   coresize = 0;
   list = NULL;
   while ((thissize = (size_t)Malloc(-1l)) >= sizeof(void *))
   {
      buf = (void **)Malloc(thissize);
      if (buf == NULL)
         continue;
      coresize += thissize;
      *buf = list;
      list = buf;
   }
   while (list != NULL)
   {
      buf = (void **)(*list);
      Mfree(list);
      list = buf;
   }
   return coresize;
}



Is there any tool which can display in "real time" the amount of ST/TT RAM available ?

Interesting point. I would expect SLB open/close functions to take care of that.


That is done if the library is loaded by different applications, but not if is loaded again by the same application. In that case you get an error.

maybe it's time to enhance this dynamic modules design instead of pushing that management to apps.


And force all users to update to the latest mint/magic so they can use the apps? I don't think that this will work. Also, i don't want to have to load/unload the module a 100 times in zView when opening a browser window in zView.

Thorsten, on zvSLB plugin model, app provides slb_open/close callbacks to plugin because it saves memory/helps plugin dev or because there is no other choice: plugin has to get back to app for SLB loading? What would happen if plugin loads SLB directly without using this app callback?


I see no other choice. The usage counting must be done by the app, since that is the only central place. And for malloc/free at least, having a static heap in each module to maintain the blocks is just not going to work. Same for fopen/fclose/open/close, because that would mean each modules has its own list of files which are currently in use.

Only thing that could be done eventually is to reduce the number of callbacks, by moving functions like qsort/bsearch (and maybe some others) to the modules again. But to be honest, i'm not in the mood to invest that effort again only to find out that it was for nothing.

ThorstenOtto
Atari Super Hero
Atari Super Hero
Posts: 815
Joined: Sun Aug 03, 2014 5:54 pm

Re: SLB 'devkit' ?

Postby ThorstenOtto » Sat Sep 14, 2019 6:06 pm

AnthonyJ wrote:Could the modules know about each other?


No, definitely not. Maybe not all of them are installed, or not loaded, or someone writes a new module that is not known yet.

the modules themselves reference counting users?


That does not work either, because each different application gets its own SLB handle and exec function.

JeanMars
Captain Atari
Captain Atari
Posts: 177
Joined: Fri Apr 09, 2010 5:15 pm
Location: France
Contact:

Re: SLB 'devkit' ?

Postby JeanMars » Sat Sep 14, 2019 8:55 pm

Hi Thorsten,

Malloc(-1) only gives you the size of the largest block, that might be the same if the module was loaded somewhere else. To get the total memory, you can use Dfree(35) on Mint. For Single-TOS, you have to allocate blocks until you get NULL, then free them again. In ORCS, i use something like this:

Much better now, thanks ! :D
Thanks also to lp for providing me MEMWATCH.PRG which does exacly that. Also noted that sysinfo available rom a right clivk on EasyMint distribution does the same job.

That is done if the library is loaded by different applications, but not if is loaded again by the same application. In that case you get an error.

OMG!!! That's quite a limitation mandating SLB dependencies to other SLBs to be managed by application.

And force all users to update to the latest mint/magic so they can use the apps? I don't think that this will work.

I was thinking of a possibility to install (from an auto program) news traps that will call original SLB traps and work this limitation out. Just a thought, did not think about how to implement.

Also, i don't want to have to load/unload the module a 100 times in zView when opening a browser window in zView.

You don't have to do this each and every time you open an image. The current thing I'm now implementing in Vision is:
- Only load a plugin when an image is about to get loaded from it (you have to maintain some kind of database to map file extension to plugins but we already talked about that)
- When an image is about to get loaded (reader_init outcome), you know the image dimensions and can estimate the expected memory to be allocated. If current available memory is not enough, just unload some plugins.
This is what Vision is doing now (unload less used plugins as long as this available memory is not enough) and it looks pretty good on my last tests.

ThorstenOtto
Atari Super Hero
Atari Super Hero
Posts: 815
Joined: Sun Aug 03, 2014 5:54 pm

Re: SLB 'devkit' ?

Postby ThorstenOtto » Sat Sep 14, 2019 11:24 pm

JeanMars wrote:I was thinking of a possibility to install (from an auto program) news traps that will call original SLB traps and work this limitation out. Just a thought, did not think about how to implement.


Then you are back to the LDG system, which needs an extra program in the auto folder, but this time even if the library is not shared. That was another goal of the SLBs, to get rid of that dependency. Noto speak about that is wil be extremely difficult to implement that (think about some SLB and/or app crashing).

When an image is about to get loaded (reader_init outcome), you know the image dimensions and can estimate the expected memory to be allocated. If current available memory is not enough, just unload some plugins.


That might work for vision where you only load one image at a time. But for zView you will more than likely unload the plugins that are needed for the next image. Not to mention that the memory needed to load the image is usually much higher than the memory for the plugin itself (~16K for most of them).

This is what Vision is doing now (unload less used plugins as long as this available memory is not enough) and it looks pretty good on my last tests.


This would even add more complexity to the all the plugins, since you then have to reload it when calling get_option to retrieve the codecs info like version, author etc.

Just believe me, even if the current design might not be perfect, its limitations are mostly caused by facts outside of the control of the libraries that cannot easily be changed (if at all), and i have given it quite some thoughts, to make it usable as easily as possible. And no, i don't count a dozen small wrapper functions for PureC or so extra hassle; took me about 30min to implement that.

JeanMars
Captain Atari
Captain Atari
Posts: 177
Joined: Fri Apr 09, 2010 5:15 pm
Location: France
Contact:

Re: SLB 'devkit' ?

Postby JeanMars » Sun Sep 15, 2019 9:59 am

Hi Thorsten,

Then you are back to the LDG system, which needs an extra program in the auto folder, but this time even if the library is not shared.

This model does not look bad to me, I always prefer having a common thing to deal with a problem rather than having every application making its own implementation.

Noto speak about that is wil be extremely difficult to implement that (think about some SLB and/or app crashing).

Well, if a SLB or an app crashes, I guess the counter/memory is not updated as well in the current zvSLB model.

That might work for vision where you only load one image at a time. But for zView you will more than likely unload the plugins that are needed for the next image.

I don't get you: I believe for each image zview calls reader_init/n x reader_read/reader_quit sequence. All course, the plugins that will be needed for loading the image are not part of the list of the ones to be released.

Not to mention that the memory needed to load the image is usually much higher than the memory for the plugin itself (~16K for most of them).

Correct. However, if you load them all (~100 plugins right now), you reach some significant amount of memory wasted. And BTW, there is a *much* simpler way then: statically link all modules to the app..

This would even add more complexity to the all the plugins, since you then have to reload it when calling get_option to retrieve the codecs info like version, author etc.

This information can be part of the 'database' (ini file in Vision case) you build when app discovers a new/updated plugin.

Just believe me, even if the current design might not be perfect, its limitations are mostly caused by facts outside of the control of the libraries that cannot easily be changed (if at all), and i have given it quite some thoughts, to make it usable as easily as possible. And no, i don't count a dozen small wrapper functions for PureC or so extra hassle; took me about 30min to implement that.

Agree, the OS should provide a better mecanism here. That's why I still believe the proper approach is to address this from an OS extension point of view, not by requiring micro-management from each app.
Note that if you don't like the prg in auto folder, it can be part of the app package and started in case it is not yet started. At least, this would be a simple easy check at start and each app won't have to worry about which dependencies each module has to return the current SLB handles to the plugin.
Not saying it's easy, I'm not to aware of internal SLB stuff, but if we can find a way to make a SLB load directly another SLB and take care about the counter, that would much better. In case of Vision or zView app, I agree that the SLB plugin dependencies are under control (basically zlib, exif,...) but in the general case that would be a nightmare.

ThorstenOtto
Atari Super Hero
Atari Super Hero
Posts: 815
Joined: Sun Aug 03, 2014 5:54 pm

Re: SLB 'devkit' ?

Postby ThorstenOtto » Sun Sep 15, 2019 10:38 am

JeanMars wrote:Well, if a SLB or an app crashes, I guess the counter/memory is not updated as well in the current zvSLB model.


But it does not matter, because the counter is in the app, and it will be killed. In a resident auto-folder program, you have to catch that case, or the next time you start the app no module will be loaded, because it thinks it is still in memory. Even worse, it will give you a handle for a module that does not exist anymore.


I don't get you: I believe for each image zview calls reader_init/n x reader_read/reader_quit sequence. All course, the plugins that will be needed for loading the image are not part of the list of the ones to be released.


In a browser window you can have all kind of images. The reader_init for the current image does not know which image is found after the current one and which plugin is needed for that.

there is a *much* simpler way then: statically link all modules to the app..


You can't be serious about that...

Not saying it's easy, I'm not to aware of internal SLB stuff, but if we can find a way to make a SLB load directly another SLB and take care about the counter


I would say it is almost impossible to handle that cleanly, given that there are at least 3 different OS which behave very different in that matter. There is a reason why LDG needs 3 different programs plus a config CPX to handle even simple cases on MagiC.


but in the general case that would be a nightmare.


Why? Even if i would have to add another library, that are just 3 lines of codes added, in the switches.

JeanMars
Captain Atari
Captain Atari
Posts: 177
Joined: Fri Apr 09, 2010 5:15 pm
Location: France
Contact:

Re: SLB 'devkit' ?

Postby JeanMars » Sun Sep 15, 2019 1:23 pm

Hi Thorsten,

You can't be serious about that...

Agree that my wording might be a bit too much but think about it: what are the pro/cons of dynamic libraries vs static libraries?
Pros:
1- Not having everything in memory as app can decide only to load the code only when needed
2- Not having to recompile the app when a plugin is new/updated
Cons:
1- More complexity on app side
2- Need to define an interface between app and plugin

Here by loading all plugins even the ones that won't be used, you are losing Pro1 (even by adding more used memory for plugin managenent) and putting more complexity and dependencies on Con1 and Con2.
Just to allow a plugin to use functions of another plugin...
To me it's not worth it but of course you are free to decide for the code you maintain.

Why? Even if i would have to add another library, that are just 3 lines of codes added, in the switches.

Fair enough. However I like the idea of letting the plugin deal with whatever it needs without requiring the app to know each and every dependency it needs to work. As a user, it's necessary to know that lib A requires lib B, but as a programmer I just don't want to put code in my app about lib B for lib A to work with.

For the rest, I'm no expert here but I believe you when you say it might not be simple.

OL
Atari Super Hero
Atari Super Hero
Posts: 519
Joined: Fri Apr 01, 2005 6:59 am
Contact:

Re: SLB 'devkit' ?

Postby OL » Sun Sep 15, 2019 2:32 pm

AnthonyJ wrote:
For that to work, the app needs at least to maintain some kind of reference counter. And that can also only been done by the app since the modules don't know about each other.

I haven’t looked at any of the code / current design so could be completely wrong, but perhaps a potential solution to break this assumption?

Could the modules know about each other? Or perhaps more precisely, the modules themselves reference counting users? So a zlib SLB can be loaded by each SLB that needs it, and the zlib SLB won’t be released until it has 0 user?

Apparent leak on releasing LDG could be Malloc vs malloc?


On all my module memory alocation are done by hand using system Malloc, this is for exemple the case of mesagl.ldg, tiny_gl.ldg, screen.ldg ....
Note this way not permit to share library or the library need manage client. Another way is to use mem.ldg that do the same but not help to share. Another way is perhaps the Mikro branch of LDG, in this case lib can use stdlib from application, it not help to share library. To share ldg.prg should help but for me it not work as it should and crash, I write it, I fix some issues and lost source code unfortunately, but even not sure it work and not sure allocation memory can be shared.
My point of view share is not really usefull, there is not enough application using such type of system. Load several time same lib as stdlib I agree Thorsten can take in some case a lot of memory and this is the case with Zview when we have to load a lot of plugin. If we add as for ldg Mikro branch use of stdlib from client it is quite nice but what we can expect it is working with same lib programer have done the test and perhaps not with another compiler or another stdlib, we could have unstable system and lib in this case could not be used by GFA software for example.
So my point of view if we want something working or the system provide memory management and stdlib or stdlib should be in library itself. LDG can work with any system, no need of Mint, can run under Magic or TOS, not perfect for sure but not so bad, for a week I'm back as programmer under Atari after more of one year not working, I have a lot to do, but first I'm going to try have better ldg.prg and for memory sharing Mint should provide this (something near bit 14 of Mxalloc but with client management to free memory when no more client for the memory block), but I can do it in MyAES and next version will provide this, this is not too difficult to do.

Now I'm not the programmer of software such as zview but my point of view it is not difficult to reduce highly memory need even with ldg module, just not load what is not need! I can compare color icon load by TOS with Magic or MyAES (don't know for XaAES), or the system translate all icon at ressource load or translate icon only when they are used at fly, TOS translate all at load Magic or MyAES only when it is need to display and manage cache, start software is far faster. For plugin it can be the same, application can learn link between image and plugin, this is not difficult to do and finally you will see at 95% of the time only jpeg and png are need to be loaded! Ok a little bit more complex to do but not too much!

Olivier
OL

ThorstenOtto
Atari Super Hero
Atari Super Hero
Posts: 815
Joined: Sun Aug 03, 2014 5:54 pm

Re: SLB 'devkit' ?

Postby ThorstenOtto » Sun Sep 15, 2019 5:29 pm

JeanMars wrote:what are the pro/cons of dynamic libraries vs static libraries?


In the case of zView, the main pro is that you can *add* new modules any time. Or disable modules that you don't need. How would you have added support in Vision to load lots of image formats without Lonnys codecs? You don't have their source.

JeanMars wrote:Here by loading all plugins even the ones that won't be used, you are losing Pro1


You should stop exaggerating that fact. This can and will change. It is just not implemented yet.

Just to allow a plugin to use functions of another plugin...


None of the plugins uses functions from any other plugin, what makes you think so?

To me it's not worth it but of course you are free to decide for the code you maintain.

However I like the idea of letting the plugin deal with whatever it needs without requiring the app to know each and every dependency it needs to work.


I'm a bit tired of having to explain the reasons for the design again and again.

I just don't want to put code in my app about lib B for lib A to work with.


Are you rewriting the standard C-library each time you write a new program? No, you don't, you just use the one that is available. Put the code i added into a separate file, and it is not different.

ThorstenOtto
Atari Super Hero
Atari Super Hero
Posts: 815
Joined: Sun Aug 03, 2014 5:54 pm

Re: SLB 'devkit' ?

Postby ThorstenOtto » Sun Sep 15, 2019 5:52 pm

OL wrote:On all my module memory alocation are done by hand using system Malloc


If all libraries would use that, they would be fine. But the problem with Malloc is that you sooner or later run out of memory pool blocks from the OS if you do lots of small allocations, at least with SingleTOS and MagiC, and on MiNT it would waste a lot of memory, since all allocations are rounded up to 8k blocks.

lib in this case could not be used by GFA software for example.


It can, with a bit of effort. I have already written the interface code to use zlib from GFA, for example. there haven't been any comments though in viewtopic.php?f=69&t=37155 ;) So it was just done as a prove of concept.

JeanMars
Captain Atari
Captain Atari
Posts: 177
Joined: Fri Apr 09, 2010 5:15 pm
Location: France
Contact:

Re: SLB 'devkit' ?

Postby JeanMars » Sun Sep 15, 2019 6:54 pm

Hi Thorsten,

sorry I realize this dicussion is starting to bug you and that was not my objective at all.
Let's just conclude we have different views on what a plugin/dynamic lirary is and how it should behave regarding apps and that's it. You are very free to have your opinion on this as well as me.

It would be such a crazy thing to do to have some escalation here considering the number of our 'customers' :-)

Cheers,
Jean

OL
Atari Super Hero
Atari Super Hero
Posts: 519
Joined: Fri Apr 01, 2005 6:59 am
Contact:

Re: SLB 'devkit' ?

Postby OL » Sun Sep 15, 2019 7:25 pm

ThorstenOtto wrote:
OL wrote:On all my module memory alocation are done by hand using system Malloc


If all libraries would use that, they would be fine. But the problem with Malloc is that you sooner or later run out of memory pool blocks from the OS if you do lots of small allocations, at least with SingleTOS and MagiC, and on MiNT it would waste a lot of memory, since all allocations are rounded up to 8k blocks.

lib in this case could not be used by GFA software for example.


It can, with a bit of effort. I have already written the interface code to use zlib from GFA, for example. there haven't been any comments though in http://atari-forum.com/viewtopic.php?f=69&t=37155 ;) So it was just done as a prove of concept.


This is what mem.ldg do. And for ports I directly manage Malloc by myself or number of alloc is low no issue or more important as Mesa, I have done a small memory management not as complex as stdlib malloc but enough to not do too much memory allocation! In fact first ldg I have made was mesa and it take me some time to fix memory issue!
For GFA I was just speaking of ldg.prg only, this is the only reason I see to use this buggy TSR for the moment! Probably better to use SLB as it is implemented in system.

Olivier
OL

ThorstenOtto
Atari Super Hero
Atari Super Hero
Posts: 815
Joined: Sun Aug 03, 2014 5:54 pm

Re: SLB 'devkit' ?

Postby ThorstenOtto » Sun Sep 15, 2019 10:39 pm

OL wrote:I have done a small memory management not as complex as stdlib malloc but enough to not do too much memory allocation!


It doesn't matter whether it is complex or not. In fact it is not that difficult, if you look at the source in mintlib. The problem here is that you have to maintain a list, array or whatever in your library. Assuming you allocate blocks from the OS in chunks of lets say 8K, then
- app1 allocates some memory, lets say 100bytes
- your library Malloc()s a block from the OS, gives the app that 100 bytes, and marks the rest as free
- app2 allocates 100bytes. You give it some area from the free space
- app1 terminates. Now you are doomed, because the Malloc was done on behalf of app1, the OS frees the whole block, and the area you gave to app2 does not longer exist.

Such problems are not specific to ldg or slb. They are just caused by lack of support from the OS for "real" shared libraries.

OL
Atari Super Hero
Atari Super Hero
Posts: 519
Joined: Fri Apr 01, 2005 6:59 am
Contact:

Re: SLB 'devkit' ?

Postby OL » Mon Sep 16, 2019 6:43 pm

ThorstenOtto wrote:
OL wrote:I have done a small memory management not as complex as stdlib malloc but enough to not do too much memory allocation!


It doesn't matter whether it is complex or not. In fact it is not that difficult, if you look at the source in mintlib. The problem here is that you have to maintain a list, array or whatever in your library. Assuming you allocate blocks from the OS in chunks of lets say 8K, then
- app1 allocates some memory, lets say 100bytes
- your library Malloc()s a block from the OS, gives the app that 100 bytes, and marks the rest as free
- app2 allocates 100bytes. You give it some area from the free space
- app1 terminates. Now you are doomed, because the Malloc was done on behalf of app1, the OS frees the whole block, and the area you gave to app2 does not longer exist.

Such problems are not specific to ldg or slb. They are just caused by lack of support from the OS for "real" shared libraries.


Yes I fully agree with you and it is why mesa_gl and tiny_gl are not sharable, there is a flag for this in ldg system. Now for the lib there is a way not simple, but for each client you can alloc memory so memory is ,not shared.
Now what I have done in ldg.prg, I use SHM as I understand should lock memory if there is still a client or a bloc duplicated of it (and this is here a possible issue because documentation said this bloc should not contain absolute address because it can be at different address from one client to the other, I don't know what Mint do exactly but for me it's not a copy but the same bloc). I think it work I do several tests and after some fixs I was near sure it work unfortunately lost my work.
OL


Social Media

     

Return to “Coding”

Who is online

Users browsing this forum: No registered users and 3 guests