Uwe Schröder Blog

My delivered features via source-forge should ALL be "downwards compatible" unless otherwise well described in particular.
This means for instance: you could use Lnkdlst v1.0 as well as Lnkdlst v3.4.
a: If you had no specific reason to change to the newest version, you must not, but you should have the option to do this without harm and much efford (may be with little adaptions).
b: If you think a newer version (usually containing new features and bug fixes) has to be used instead of an version you already use yet, then you are invited to change the version - it should be compatible (with little well described restrictions).
c: If you had issues by using a newer version, than -- PLEASE -- let me know; you could send a message to me via sourceforge or directly per eMail to -> petra DOT busse DOT ste AT freenet DOT de.
d: If you has enhanced an version by yourself, and now had more to do by changing the version, you could send me a mail with a patch, the feature name (e.g. Lnkdlst) and the basic version of the feature including a little description what the patch should do. I'll try to enhance the latest version with your changes if i find it deals with generic, for all optional useful new features. But i could not promise that it will work...
-
As one example for a - may be - good idea to change from a later version to a newer one is feature ringBufU, version 0.2.1:
With this version of ringBufU you would HAVE the option to accelerate the Ring-buffer access in several steps. This reduce the safe handling of using the API (safety is not costless in time).
For instance you had found issues with ringBufU in your application and now use it for a longer time without getting issues. Now you could change the version and speed up the access, as you like (upto simelar the same speed as in C++ std.libraries, see example test code for further info).
If you again get issues in this code sections it is easy to switch back again to the very safe variant of ringBufU. Although now you may have other trouble with race-conditons (i.e. issue may no longer occur in safe variant), but in main i think it should work.

Every programmer knows: the object you want to access have to exist.
But in some cases it is difficult to ensure. I.e. if you have an object-ptr, how could you know that the life time of the specific object ptr at least is valid NOW. This is sometimes not easy to analyse in complex code.
-
To have more stability i integrate access protection for some of my features (projects):
- ringBufU : usually (normal compilation, release build-type) wrong pointers to CPobjs of a ringBufU buffer instance will not result in a crash. If you use the wrong pointer in the instance access macro, and the pointer does not point to a now valid RingBufU buffer CPobj, you'll only get a specific return code. When you detect this code you should clean up your application, at least stop&restart. But you could remember this wrong behavoiur and could make further specific investigation why this wrong access happens. Also it may be possible to integrate work-arounds in the specific case till the solution has been found.
- -
- Lnkdlst : Normally no pointer check has been done. But you could enable (in debug release type partly done for the given test applications) a LinkedListElement (LLEl) check. This ensures - on run-time - that (i) the LLEl is yet valid and (ii) it will not be put in a list, when already done (one LLEl could not be in 2 lists at a time of course). When some failure is detected there will be an program exit forced (own macros, you could adapt this for your needs of course).
- -
- Lnkdlst, OAList01 CPobj : The init of usage of this CPobjs has to be done. If you have an configurable application (for instance) with multiple modular features which could be freely integrated and if those optional features uses OAList01, every feature could call the OAList init function with a name (of the using feature). Hence init is ensured either if one ore more OAList01 users needs this feature. And deinit is dynamically possible in the same way.
- -

Overview about the EventUni framework:

main:
    + init evu global
    init own structures for work with evu
    ...

thread:
    + create evu object
    + enable 1st evu events (by Ident)
    -remark- other events could be enabled inside or outside of this thread,
             Events can also be disabled at "object" (only C) lifetime. 
             without enabling the events this evu will not wait for them; 
             instead those events will be stored in a specific queue and 
             will be served after enabling.
             predefined event identifiers are out-of-the-box usable and 
             opt. you could instantiate own ev.Idents
    select-feature:
        opt. + enable file-discriptor events (to say: act with reading /.. on this fd)
    timeout-feature:
        opt. + starting of timers (for timeout events in case of expiration)
    ...

    service-loop:
        + wait-for-event
        -remark- 'wait' is halting in OS (only if no 
                 enabled event is already waiting in a queue), 
                 this thread is the worker-thread for this evu object, 
                 other threads a/o select and timeout feature could 
                 inject events (e.g. auto ev creation by an enabled 
                 select socket fd for the Receive event)
        + get-next-event -> ev
        make smth. depending on ev.Ident (and more)
        + free event ev 
        ...

    end-of-seevice-loop

All lines with a plus-sign (+) are supported by EventUni already.
The embedded timeout feature (via TOTimer) is not yet full properly tested - testing is going on.
Let me know if you are interested in EventUni or if you like to be an alpha-tester.

I'm working on a new framework for events, to have a fully event-driven thread.
It could combine condition-variable halting to waiting for events (from other threads) and waiting in selects, to generate implicit events for waiting file-descriptors (read/write/exception) parallel to the other events. Outstanding threads do not know wether the event-thread is currently halting on a condition-variable or in the POSIX select-function; the send-Event function works either. (Of course you could only wait at one position in an event-thread at a time, hence either cond.var.-waiting or select-waiting is active, depending on the settings (API-calls) from the framework-user).... read more