We tend to build new APIs along with our needs to make
sure that these APIs are actually useful. ASO is like that.
It was written primarily to abstract out the primitives
required to support concurrency in CDT and Vmalloc.
It is, by no means, a complete library for all
traditional atomic operations. The available locking
routine basically implements spin-lock with no nesting.
As time goes on, new primitives will be added.
Mutex will probably be added around when I start
hacking Sfio because of sfmutex().
Phong
> From olga.kryzhanov...@gmail.com Thu Aug 16 10:22:01 2012
> Subject: Re: Putting openat() emulation into libast?
> To: Glenn Fowler <g...@research.att.com>, Phong Vo <k...@research.att.com>
> Cc: ast-developers@research.att.com, d...@research.att.com,
> roland.ma...@nrubsig.org
> Phong, how do I use aso to get an exclusive lock/mutex, and release
> it? Can a aso lock/mutex be nested?
> Olga
> On Thu, Aug 16, 2012 at 4:16 PM, Glenn Fowler <g...@research.att.com> wrote:
> >
> > any locking/critical regions will have to use aso
> > because libast itself does not require -l*thread*
> >
> > On Thu, 16 Aug 2012 16:11:16 +0200 =?KOI8-R?B?z8zYx8Egy9LZ1sHOz9fTy8HR?=
> > wrote:
> >> Glenn, is the general plan of putting a openat() emulation into libast
> >> acceptable for you? I found that Roland wrote one in 2004 with threads
> >> in mind, and that it only needs polishing and testing. If you agree to
> >> take it I can spend some time this evening on it.
> >
> >> Olga
> >
> >> On Thu, Aug 16, 2012 at 1:20 AM, Glenn Fowler <g...@research.att.com>
> >> wrote:
> >> >
> >> > On Thu, 16 Aug 2012 01:09:29 +0200 =?KOI8-R?B?z8zYx8Egy9LZ1sHOz9fTy8HR?=
> >> > wrote:
> >> >> Glenn, have you ever considered putting an openat(), fstatat(),
> >> >> mkfifoat() emulation into libast, if the base operating system does
> >> >> not have such calls? I have been trying more tests with the at() apis
> >> >> but I am not happy to trash much of libshell with lots of #ifdef
> >> >> AT_CWD tests if there is a better option.
> >> >
> >> >> AFAIK a lot of the at() calls can be emulated by using
> >> >> /dev/fd/${dirfd}/${path} or /proc/${pid}/fd/${dirfd}/${path}. I just
> >> >> do not know, are there cases where /dev/fd or /proc/${pid}/fd are not
> >> >> available (chroot environments?)?
> >> >
> >> > there are a lot of systems with lame or no /proc
> >> > and it will be hard to work around systems with no O_search
> >> >
> >> > but let me think a bit on that
> >> > if we didn't have to worry about dir fd's across exec (probably rare
> >> > right now)
> >> > we might be able to cache emulated open(O_search) paths with <dev,ino>
> >> > keys
> >> > on systems that don't support /dev/fd/<FD>/<PATH> pr
> >> > /proc/<PID>/fd/<FD>/<PATH>
> >> >> Olga
> >> >> --
> >> >> , _ _ ,
> >> >> { \/`o;====- Olga Kryzhanovska -====;o`\/ }
> >> >> .----'-/`-/ olga.kryzhanov...@gmail.com \-`\-'----.
> >> >> `'-..-| / http://twitter.com/fleyta \ |-..-'`
> >> >> /\/\ Solaris/BSD//C/C++ programmer /\/\
> >> >> `--` `--`
> >> >
> >
> >> --
> >> , _ _ ,
> >> { \/`o;====- Olga Kryzhanovska -====;o`\/ }
> >> .----'-/`-/ olga.kryzhanov...@gmail.com \-`\-'----.
> >> `'-..-| / http://twitter.com/fleyta \ |-..-'`
> >> /\/\ Solaris/BSD//C/C++ programmer /\/\
> >> `--` `--`
> >
> --
> , _ _ ,
> { \/`o;====- Olga Kryzhanovska -====;o`\/ }
> .----'-/`-/ olga.kryzhanov...@gmail.com \-`\-'----.
> `'-..-| / http://twitter.com/fleyta \ |-..-'`
> /\/\ Solaris/BSD//C/C++ programmer /\/\
> `--` `--`
_______________________________________________
ast-developers mailing list
ast-developers@research.att.com
https://mailman.research.att.com/mailman/listinfo/ast-developers
