Re: [PATCH]: add missing lock_acquire/release in __fp_lock_all/__fp_unlock_all

["Thomas Pfaff" <thomas dot pfaff at gmx dot net>]

Jeff Johnston wrote:
> Thomas Pfaff wrote:
> > Thomas Pfaff wrote:
> >
> >> This locks have been unfortunately removed by me.
> >>
> >> 2003-03-26  Thomas Pfaff  
> >
> >   2004-03-26
>
> I did see this, but I kind of prefer it this way.  The name of the
functions
> imply locking all the files so I'm not sure I like the file-list lock
being left
> locked under the covers.  The calls to _fwalk will use the __sfp_lock.
>
> There are also no newlib callers of this function and any Cygwin or newlib
code
> could make the calls themselves as needed.  What specific usage do you see
for
> this function that the file-list lock is also required?
>

I want to make sure that no threads alters the file pointer list during
fork.

When i introduced __fp_lock_all/__fp_unlock_all i mentioned that these
functions can be called at fork time to make sure that no other thread than
the
forking one owns a lock on a file to avoid a deadlock in the child process.
The file locking on cygwin works with pthread mutexes that remain locked
after a fork, even if the locking thread is no longer valid, so you must
make
sure that the forking thread owns the lock. Pthreads define a function named
pthread_atfork for this purpose.

__fp_lock_all is called before fork in parent process, __fp_unlock_all in
the parent and the child process afterwards.

Between lock_all/unlock_all  the file pointer list should not be modified,
therefore i added __lock_acquire/__lock_release.
The removal was an accident.




-- 
+++ NEU bei GMX und erstmalig in Deutschland: TÜV-geprüfter Virenschutz +++
100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz