This is the mail archive of the
newlib@sources.redhat.com
mailing list for the newlib project.
Query concerning use of flockfile/funlockfile in stdio FILE relatedfunctions
- From: Antony KING <antony dot king at st dot com>
- To: newlib at sources dot redhat dot com
- Date: Mon, 06 Sep 2004 18:44:34 +0100
- Subject: Query concerning use of flockfile/funlockfile in stdio FILE relatedfunctions
- Organization: STMicroelectronics (R&D) Ltd
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).
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).
Any other suggestions ?
Cheers,
Antony.
--
-----------------------------------------------------------------
Antony King |
STMicroelectronics (R&D) Ltd. |
Bristol, BS32 4SQ. United Kingdom. |