This is the mail archive of the newlib@sources.redhat.com mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Query concerning use of flockfile/funlockfile in stdio FILE relatedfunctions


Antony KING wrote:
Hello,

I have a query concerning the use of the flockfile/funlockfile functions in the stdio sub-component of newlib. It relates to a requirement we have of being able to call the sprintf/sscanf class of functions from interrupt handlers in our RTOS.

One of the restrictions of interrupt handlers in our RTOS is that they cannot block on synchronisation objects which is unfortunate since the sprintf/sscanf class of objects implicitly use the locking API defined in sys/lock.h via flockfile/funlockfile (I have implemented the locking API using the synchronisation objects available in our RTOS).


Anthony, in the sprintf/sscanf case, as you have noted, the lock object is only known to the sprintf or sscanf functions (they are part of local FILE objects). Thus, there should never be a blocking situation which technically meets the "letter of the law" stated above. Is the restriction more strict than you have noted?


I have noticed that the local FILE lock objects are not being initialized which is an error :(.

This restriction is not a problem when using FILE objects created via fopen et al since they normally refer to resources which require the proper thread protection afforded by the locking API. However for the sprintf/sscanf class of functions using the locking API is unnecessary since the FILE objects created by these functions for use by the "real" functions _vfprintf_r/__svfscanf_r should be inherently thread safe (as they are allocated off the stack).

It should therefore be possible to dynamically detect this scenario and not use the locking API and hence allow me to use the sprintf/sscanf functions from my interrupt handlers.

Ideally I would like to add a flag to the _flags field of the FILE structure to indicate whether a lock object is present or not but unfortunately there are no free bits left. Another possibility would have been to use the fact that the sprintf/sscanf fucntions set the _file field of the FILE structure to -1 but thus is not reliable since it can take the value of -1 in other instances.

One thought is to extend the locking API to to include "not initialised" initialiser APIs whose purpose is to allow the locking API acquire and release methods detect this state and ignore the lock/unlock requests. Its not very nice but would work without changing the layout of the FILE structure (by increasing the size of the _flags field from 16 bits to 32 bits). Also I am uncertain how this change to the locking API would impact other implementations (e.g. linux/cygwin).


The locking API should not be changed. It is easy enough to check for the __SSTR flag to avoid locking. This flag is set for all the string printf operations but isn't currently used for the sscanf set.


-- Jeff J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]