Is libInit() protected from switching i.e not running multitask?

[gdridi]

Hello!

I see difference between running my library between AOS4.1FinalEditionUpdate0 and AOS4.1FEUpdate2

Is there a Forbid() done by the Kernel when libInit() is called to initialize library code ? That was removed in AOS4.1FinalEditionUpdate2 ?

This leads to instability when launching multiple instances of my library at the same time. So libInit() must be protected by a Forbid().

This could explain mysterious bug ?
When launching multiple instances of program in parallel that use a same library.

Sincerely yours,

DGILLES

[Olaf Barthel]

Hello!

I see difference between running my library between AOS4.1FinalEditionUpdate0 and AOS4.1FEUpdate2

Is there a Forbid() done by the Kernel when libInit() is called to initialize library code ? That was removed in AOS4.1FinalEditionUpdate2 ?

This leads to instability when launching multiple instances of my library at the same time. So libInit() must be protected by a Forbid().

This could explain mysterious bug ?
When launching multiple instances of program in parallel that use a same library.

Sincerely yours,

DGILLES

For disk-loaded libraries and devices, the init code is invoked by the ramlib process, which loads the respective executable file from disk, searches for a resident tag and the relevant setup information. Because the ramlib process performs this task one library and device at a time, there is no Forbid() locking involved. The device/library init code is invoked by ramlib, and it ought to return a pointer to the library/device base, if successful, or NULL if unsuccessful. Arbitration with Forbid()/Permit() locking is used only with the open, close and expunge functions.