This is the mail archive of the newlib@sourceware.org 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: [RFC] statically initialize spu FILE values


Patrick Mansfield <patmans@us.ibm.com> wrote:
> On Mon, Apr 09, 2007 at 10:53:57AM +0900, Kazunori Asayama wrote:
> > I propose to modify CHECK_INIT macro as following instead of remove
> > it, to minimize runtime overhead and code size, and still to do
> > cleanup correctly:
> > 
> >     #define CHECK_INIT(ptr) ((ptr)->__sdidinit = 1, (ptr)->__cleanup = __cleanup)
> 
> I wanted to remove all those calls. And we are still missing close of
> files opened via open.
> 
> Are you OK with closing all opened files (for both fopen and open) in libspe? 
> 
> Then we could remove stdio.c and the spu CHECK_INIT.

I basically agree. But unfortunately, correspondence between SPE
context and FILE is NOT managed in the current libspe implementation
(both 1 and 2), and in addition it's quite difficult to implement such
management routine w/ the current libspe specification because a
'library callback' has no way to know which SPE context calls the
callback.

To implement correct cleanup sequence in libspe, I suppose that the
following works will be needed:

 - to change or extend the libspe specification of library callback in
   order to make it possible that callbacks can handle SPE context in
   the callbacks,
 - to implement the new spec,
 - to add management routine of correspondence between SPE context and
   FILE in libspe, and
 - to add cleanup sequence in libspe.

In my personal opinion, I think that the current spec of callback is
insufficient not only for default callbacks but also for application
specific callbacks, and that some kind of change or extension of the
spec is needed as mentioned above.

Anyway, at this time, could you leave the current behavior (SPU newlib
performs cleanup) until libspe will be equipped with sufficient
mechanism ?

--
(ASAYAMA Kazunori
  (asayama@sm.sony.co.jp))
t


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