You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "Marc G. Fournier" <sc...@hub.org> on 2002/05/03 14:39:15 UTC
libapr* ...
A couple of questions here ... I'm looking at the APR work that has been
done, specifically in relation to the shared memory on win32 work, with an
eye to making use of it to work towards a 'native' version of PgSQL
instead of having to run through Cygin ...
Reading the license itself, use of that code shouldn't constitute a
problem, nor conflict with our BSD license ... unless I'm reading it
wrong, they are relatively complementary ... is this correct?
Assuming that I am correct, and that such use is/would be acceptable, has
anyone thought to pull it out of the apache dist and create a
libapr.tar.gz package, similar to the libapreq.tar.gz stuff I see on the
ftp site?
Thanks ...
Re: libapr* ...
Posted by Ryan Bloom <rb...@ntrnet.net>.
This should be on dev@apr.apache.org. I have copied that list.
On Fri, 3 May 2002, Marc G. Fournier wrote:
>
> A couple of questions here ... I'm looking at the APR work that has been
> done, specifically in relation to the shared memory on win32 work, with an
> eye to making use of it to work towards a 'native' version of PgSQL
> instead of having to run through Cygin ...
GREAT!
>
> Reading the license itself, use of that code shouldn't constitute a
> problem, nor conflict with our BSD license ... unless I'm reading it
> wrong, they are relatively complementary ... is this correct?
The Apache license is BSD based, so you shouldn't have any problems.
> Assuming that I am correct, and that such use is/would be acceptable, has
> anyone thought to pull it out of the apache dist and create a
> libapr.tar.gz package, similar to the libapreq.tar.gz stuff I see on the
> ftp site?
Yes we have, and this is definately in plan. The problem recently has
been one of time rather than desire. I believe most of us would like to
do a release of APR, and we would like to create binary and source
packages, but we just haven't had time. I personally, am finishing a
major project in the next month, and I hope to become more involved again
as soon as that project is done. My first hope is to work on the APR
distribution system.
Welcome aboard....
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
550 Jean St
Oakland CA 94610
-------------------------------------------------------------------------------
Re: libapr* ...
Posted by Ryan Bloom <rb...@ntrnet.net>.
This should be on dev@apr.apache.org. I have copied that list.
On Fri, 3 May 2002, Marc G. Fournier wrote:
>
> A couple of questions here ... I'm looking at the APR work that has been
> done, specifically in relation to the shared memory on win32 work, with an
> eye to making use of it to work towards a 'native' version of PgSQL
> instead of having to run through Cygin ...
GREAT!
>
> Reading the license itself, use of that code shouldn't constitute a
> problem, nor conflict with our BSD license ... unless I'm reading it
> wrong, they are relatively complementary ... is this correct?
The Apache license is BSD based, so you shouldn't have any problems.
> Assuming that I am correct, and that such use is/would be acceptable, has
> anyone thought to pull it out of the apache dist and create a
> libapr.tar.gz package, similar to the libapreq.tar.gz stuff I see on the
> ftp site?
Yes we have, and this is definately in plan. The problem recently has
been one of time rather than desire. I believe most of us would like to
do a release of APR, and we would like to create binary and source
packages, but we just haven't had time. I personally, am finishing a
major project in the next month, and I hope to become more involved again
as soon as that project is done. My first hope is to work on the APR
distribution system.
Welcome aboard....
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
550 Jean St
Oakland CA 94610
-------------------------------------------------------------------------------
Re: shm* equivalents (Was: Re: libapr* ...)
Posted by Aaron Bannert <aa...@clove.org>.
On Mon, May 06, 2002 at 01:20:45PM -0300, Marc G. Fournier wrote:
> This I understand, and it isn't a problem, since the only processes
> accessing 'shared memory' are child processes from the parent that
> originally creates it ...
If you're not going to support mapping of this segment by external
processes, then you don't even need to define a filename. Simply call
apr_shm_create() w/ a NULL filename and you will get anonymous shared
memory. On Unix this segment will be automatically inherited by child
processes, and on Win32 there is even some non-portable trickery you
can do to pass the map metainformation around so it looks like it was
inherited.
I took great care to document the interface calls in the apr_shm.h
file. Let me know if you have any other questions or if something
in there is unclear.
-aaron
Re: shm* equivalents (Was: Re: libapr* ...)
Posted by "Marc G. Fournier" <sc...@hub.org>.
On Mon, 6 May 2002, Aaron Bannert wrote:
> On Mon, May 06, 2002 at 10:23:39AM -0300, Marc G. Fournier wrote:
> > Just wondering if anyone has looked at (or does it already exist)
> > creating a simple SysV SHM compatibility API, so that it 'plugs-n-plays'
> > nicer with existing programs?
>
> APR's apr_shm.h API is really just for working with other APR apps.
> If you want two processes to be able to map the same segment, they both
> must use APR. What kind of functionality is missing?
This I understand, and it isn't a problem, since the only processes
accessing 'shared memory' are child processes from the parent that
originally creates it ...
The issue that I have, and may be one that makes APR not usable, is that
we don't to throw out the SysV shm* stuff that is in PgSQL, we want to
extend the code so that *if* libapr.* is available, and the person
compiling wishes to use it, they can ... so what I was planning on doing
was making wrappers in the code so that:
shmget became pg_shmget
and pg_shmget had an
#ifdef USE_APR
<do this>
#else
<use normal shmget>
#endif
but the problem is that APRs args don't seem to map to shm*'s, which means
I'd *really* have to hack the code to get it to work with APR ... unless
I'm missing something?
Re: shm* equivalents (Was: Re: libapr* ...)
Posted by Aaron Bannert <aa...@clove.org>.
On Mon, May 06, 2002 at 10:23:39AM -0300, Marc G. Fournier wrote:
> Just wondering if anyone has looked at (or does it already exist)
> creating a simple SysV SHM compatibility API, so that it 'plugs-n-plays'
> nicer with existing programs?
APR's apr_shm.h API is really just for working with other APR apps.
If you want two processes to be able to map the same segment, they both
must use APR. What kind of functionality is missing?
-aaron
shm* equivalents (Was: Re: libapr* ...)
Posted by "Marc G. Fournier" <sc...@hub.org>.
Morning all ...
Just wondering if anyone has looked at (or does it already exist)
creating a simple SysV SHM compatibility API, so that it 'plugs-n-plays'
nicer with existing programs?
For instance, what is equivalent to:
int shmget(key_t key, int size, int flag);
Looking through unix/shm.c, I would guess:
APR_DECLARE(apr_status_t) apr_shm_create(apr_shm_t **m,
apr_size_t reqsize,
const char *filename,
apr_pool_t *pool)
but, of course, the fields don't match up ...
Same with:
void * shmat(int shmid, void *addr, int flag);
being:
APR_DECLARE(apr_status_t) apr_shm_attach(apr_shm_t **m,
const char *filename,
apr_pool_t *pool)
What I'm looking to do with the PgSQL stuff is have a function:
pg_shmget()
that has an if defined(USE_APR), replace the standard shmget()/etc calls
with an appropriate apr_* call ... but looking at the APR API more
closely, I'm not sure if they are as 'similar' as I originally
thought/hoped ... :(
On Fri, 3 May 2002, Cliff Woolley wrote:
> On Fri, 3 May 2002, Marc G. Fournier wrote:
>
> > Ah, most cool ... Is there (will there be?) some sort of DLL that ppl can
> > download as well, instead of having to build it?
>
> I'm pretty sure there are no binary distributions as of yet, but I would
> think there probably *will* be after the 1.0 release.
>
> --Cliff
>
> --------------------------------------------------------------
> Cliff Woolley
> cliffwoolley@yahoo.com
> Charlottesville, VA
>
>
>
Re: libapr* ...
Posted by Cliff Woolley <jw...@virginia.edu>.
On Fri, 3 May 2002, Marc G. Fournier wrote:
> Ah, most cool ... Is there (will there be?) some sort of DLL that ppl can
> download as well, instead of having to build it?
I'm pretty sure there are no binary distributions as of yet, but I would
think there probably *will* be after the 1.0 release.
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: libapr* ...
Posted by "Marc G. Fournier" <sc...@hub.org>.
On Fri, 3 May 2002, Cliff Woolley wrote:
>
> [moving this to dev@apr where it belongs]
>
>
> On Fri, 3 May 2002, Marc G. Fournier wrote:
>
> > A couple of questions here ... I'm looking at the APR work that has been
> > done, specifically in relation to the shared memory on win32 work, with an
> > eye to making use of it to work towards a 'native' version of PgSQL
> > instead of having to run through Cygin ...
>
> Excellent!
>
> > Reading the license itself, use of that code shouldn't constitute a
> > problem, nor conflict with our BSD license ... unless I'm reading it
> > wrong, they are relatively complementary ... is this correct?
>
> That's correct. Apache and BSD licenses are compatible. We use code from
> FreeBSD in APR and Apache itself frequently, actually.
>
> > Assuming that I am correct, and that such use is/would be acceptable,
> > has anyone thought to pull it out of the apache dist and create a
> > libapr.tar.gz package, similar to the libapreq.tar.gz stuff I see on the
> > ftp site?
>
> For now you can download snapshot tarballs. A release tarball will be
> available when APR reaches 1.0 (which probably isn't that many months
> off).
Ah, most cool ... Is there (will there be?) some sort of DLL that ppl can
download as well, instead of having to build it? My goal over the next
several weeks (or less) is to have it so that if libapr is installed under
Unix, it will detect and build with its API, which is why I was wondering
about the tarballs ... be nice if similar could be done under Windows
itself :)
Thanks for the info so far though ... at least I know I'm not going down a
deadend path :)
Re: libapr* ...
Posted by Cliff Woolley <jw...@virginia.edu>.
[moving this to dev@apr where it belongs]
On Fri, 3 May 2002, Marc G. Fournier wrote:
> A couple of questions here ... I'm looking at the APR work that has been
> done, specifically in relation to the shared memory on win32 work, with an
> eye to making use of it to work towards a 'native' version of PgSQL
> instead of having to run through Cygin ...
Excellent!
> Reading the license itself, use of that code shouldn't constitute a
> problem, nor conflict with our BSD license ... unless I'm reading it
> wrong, they are relatively complementary ... is this correct?
That's correct. Apache and BSD licenses are compatible. We use code from
FreeBSD in APR and Apache itself frequently, actually.
> Assuming that I am correct, and that such use is/would be acceptable,
> has anyone thought to pull it out of the apache dist and create a
> libapr.tar.gz package, similar to the libapreq.tar.gz stuff I see on the
> ftp site?
For now you can download snapshot tarballs. A release tarball will be
available when APR reaches 1.0 (which probably isn't that many months
off).
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA