This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: POSIX close() issue
- From: "Steve Strublic" <SStrublic at hypercom dot com>
- To: ecos-discuss at sources dot redhat dot com
- Date: Thu, 13 Nov 2003 11:29:25 -0700
- Subject: Re: [ECOS] POSIX close() issue
Nick,
Any suggestions on how I could proceed, while I consider my design? This only seems to be an issue
at close() time... is there any chance of a resolution in eCos?
Steve
--------
"Space is almost infinite. In fact, we think it is infinite." -- Dan Quayle
nickg@ecoscentric.com
Sent by: To: SStrublic@hypercom.com
ecos-discuss-owner@sources cc: ecos-discuss@sources.redhat.com
.redhat.com Subject: Re: [ECOS] POSIX close() issue
11/13/03 09:26 AM
"Steve Strublic" <SStrublic@hypercom.com> writes:
>
> My question is, why perform the FILEIO_MUTEX_LOCK at all in cyg_fp_free()? cyg_file_lock()
> conditionally performs FILEIO_MUTEX_LOCK if the file's syncmode is CYG_SYNCMODE_IO_FILE.
These are locks on different mutexes. In cyg_fp_free() it is locking
fdlock which protects the file descriptors and file objects. In
cyg_file_lock() the lock is in the file object itself.
>
> Or why not also condition performing the mutex lock on this same syncmode?
>
> Or am I doing something illegal???
Unfortunately you are. The FILEIO system was not implemented with the
idea that filesystem implementations would call back into it.
--
Nick Garnett eCos Kernel Architect
http://www.ecoscentric.com The eCos and RedBoot experts
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss