You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Andrew Cheyne <ac...@gridironsoftware.com> on 2003/06/10 17:19:17 UTC
Stopping a Listening Server socket?
Hello,
I have an APR Server socket that is listening for connections in a
separate Thread. How do I stop this Socket from listening (from another
thread, for example) so I can clean up properly before exiting?
Thanks,
Andrew
PS: Code snippet:
/* Wait for a client socket connection. How do we cancel this? */
rc = apr_socket_listen( m_socket, 5 );
if ( rc == APR_SUCCESS )
{
rc = apr_socket_accept( &clientSock, m_socket, m_context );
//got a socket
break;
}
Andrew Cheyne
Senior Software Developer
GridIron Software
613.226.9445 ext. 285
acheyne@gridironsoftware.com
http://www.gridironsoftware.com <http://www.gridironsoftware.com/>
Re: Stopping a Listening Server socket?
Posted by Jeff Trawick <tr...@attglobal.net>.
Andrew Cheyne wrote:
> I have an APR Server socket that is listening for connections in a
> separate Thread. How do I stop this Socket from listening (from another
> thread, for example) so I can clean up properly before exiting?
to keep it from listening, close it
but if you really want to signal the thread to terminate, that is a
different issue
I wouldn't expect that closing the socket will for all platforms cause
that thread to wake up (seems like I tested it before and on some boxes
it woke up the accept() and on some it didn't; can't recall for sure,
though :( ).
RE: submission of new Windows rwlock code
Posted by "Marc M. Adkins" <mm...@Doorways.org>.
> At 07:05 PM 6/17/2003, Marc M. Adkins wrote:
> >I've re-coded the Windows rwlock based on the OS/2 algorithm
> implemented by
> >Brian Havard. My test program doesn't show starvation with this
> algorithm.
> >I'm assuming that the code is stable and works correctly on
> OS/2, and it's
> >essentially the same code here, plus it passes all the tests I
> know how to
> >do so I'm submitting the code for review.
>From an offline discussion with Brian Havard:
> >... in the unlock code...
> >you check the value of the readers flag outside of the critical section.
> >So in theory the readers flag could be changed between the check and the
> >critical section in which it is decremented.
> >
> >In practice, this should never happen unless a read lock is unlocked
twice.
> >So arbitrarily bad code could result in questionable behavior. I think
it's
> >a non-issue.
>
> Ok, true, that could happen. The critical section could be brought up a
> level to prevent that without any performance penalty (except for when
> attempting to unlock a lock that's not locked which shouldn't be done
> anyway).
But in my port of Brian's code I don't use a critical section, I use the
Windows equivalent of atomic variables. So while Brian could fix his
implementation easily I would have to do some more rewrite, to bring it back
into line with his version by creating a critical section in the unlock
code.
Frankly, I still think this is a non-issue in both cases. It can only
happen if the APR user writes code that unlocks more than it locks, which
indicates errors in the user code anyway. But it is potentially a hole in
the algorithm, so I figured I had to at least write it up, in case the
consensus was that a fix was in fact required.
mma
Re: submission of new Windows rwlock code
Posted by "William A. Rowe, Jr." <wr...@apache.org>.
At 07:05 PM 6/17/2003, Marc M. Adkins wrote:
>I've re-coded the Windows rwlock based on the OS/2 algorithm implemented by
>Brian Havard. My test program doesn't show starvation with this algorithm.
>I'm assuming that the code is stable and works correctly on OS/2, and it's
>essentially the same code here, plus it passes all the tests I know how to
>do so I'm submitting the code for review.
Great work! Consider this reviewed+=1.
Mr. Stoddard was correct, the patch needed style updates (I'll discard my
edited copies and replace them with his :-) Not that we don't like your own
preferred style, but as a coder working in a dozen different code bases over
the course of a week, strong style affinity within a project helps keep my
mind on the right page.
I have a few other small kibitzes. OS2 is unique from Win32 in that it will
generally provide the return value from the function, not a separate error
lookup. In general we've used apr_get_os_error() which does apr_status_t
conversion + GetLastError(). Stoddard was guilty of the same this a.m. :-)
>Somewhat to my surprise the performance test program that comes with APR
>seems to show an increase in speed of 30% - 50%. Possibly because the old
>code had two mutex waits for a read lock and the new code has one.
>
>I was initially surprised because the new code has tests on return values
>and an extra level of subroutine calling not present in the old code. Not
>to mention additional functionality: tryrdlock and trywrlock are both
>working now and starvation should be prevented. When does more
>functionality ever mean faster?
The magic of well written locking logic on single CPU boxes :-)
>I'm attaching the two changed files, which were essentially rewritten. So
>far as I can tell, the 2.1 code is still the same in CVS, so just replacing
>the files in their entirety should be sufficient. I can do diffs if that is
>better.
In general we prefer cvs diff -u3 as the format, even when a file will change
substantially. Remember that folks a year from now will be trying to follow
the delta from one commit to another, between an older and newer release.
Please always try to minimize gratuitous whitespace and decorative changes,
so that the cvs diff's are as clean as possible.
>I don't personally have CVS write access.
At the rate you are going this may change sooner rather than later :-) Please
try to observe the style guidelines, as that is a chief issue when considering
when to grant our consistent contributors their own cvs write access.
http://httpd.apache.org/dev/patches.html
http://httpd.apache.org/dev/styleguide.html
Thanks again for this rewrite, and thanks to Brian for the original logic!
Bill
time vs. file time
Posted by "Marc M. Adkins" <mm...@Doorways.org>.
A minor inconsistency, don't know if it's documented anywhere...
On Windows apr_time_now() and file modification times are the same. So a
test program that prints the current time, creates a file and prints its
modification time, and then prints the current time again will print
something like:
Currently: 1055878859474237 (1055878859.474237)
Modified: 1055878859484252 (1055878859.484252)
Currently: 1055878859484252 (1055878859.484252)
On Linux (at least Mandrake 9.0) the file modification time doesn't have the
same accuracy. The same program will print something like this:
Currently: 1055878859474237 (1055878859.474237)
Modified: 1055878859000000 (1055878859.000000)
Currently: 1055878859484252 (1055878859.484252)
I noticed this when writing some code that was checking modification
timestamps to see if files required reloading. The fact that the file
modification timestamp dropped the microseconds meant at the file load times
I was storing could be later than the file modification time even when the
file was modified later than it was loaded. Admittedly this mostly happened
during my test program, which was a fairly non-ordinary exercise of the
code...but it could occasionally happen during real use.
The solution is simple: use apr_time_sec() to drop the microseconds before
comparing the two (and treat equal values as requiring update). I don't
remember reading this in any of the APR documentation, however. I would
like to put a note in the file_stat module pointing this out, and I'm
including a patch from the httpd-2.1 tree, file apr_file_info.h, to do so.
This is merely a documentation change, no code is involved:
Index: apr_file_info.h
===================================================================
RCS file: /home/cvspublic/apr/include/apr_file_info.h,v
retrieving revision 1.40
diff -r1.40 apr_file_info.h
166a167,180
>
> /**
> * @warning
> * File system timestamps are not stored with the same accuracy on all
> * platforms. For example, on Windows 2000 they are stored to the
> * microsecond whereas on Mandrake Linux 9.0 they are stored to the
second.
> * Code that compares the result of apr_time_now() (e.g. a 'file loaded'
> * timestamp) to apr_finfo_t.mtime may only work on some platforms in
> * extreme cases, such as when a file is modified within a second of its
> * load time but the stored modification timestamp is actually earlier
> * than the previous file loaded timetamp. If this is an issue, use
> * apr_time_sec() on both operands when comparing times.
> */
>
mma
RE: read/write lockout
Posted by "Marc M. Adkins" <mm...@Doorways.org>.
> >I have code that uses a rwlock, a mutex, a condition, and an
> atomic variable
> >to provide something approaching fairness (on W2K, I haven't
> gotten around
> >to testing this on Linux yet). I can post it if anyone is interested.
>
> The OS/2 implementation (locks/os2/thread_rwlock.c) I wrote also avoids
> writer starvation in that it won't allow any new reader locks while a
> writer is waiting. It uses 1 mutex, 1 event semaphore. It should translate
> to Win32 quite easily. If you can spot any holes in my logic,
> please let me
> know :)
It looks like a straightforward conversion, but that's first glance. And
it's late. I'll take a closer look tomorrow.
How did you test for starvation? I found the testlock.c application, which
appears to test read/write fine, but I'm not sure it tests specifically for
starvation.
[I have my own test application. It is manual in nature, requiring human
review of the results, but seems to show starvation pretty well. I just ran
it on Mandrake Linux 9.0 and despite the simplicity of the UNIX code (it
just uses the read/write lock) there appears to be no starvation on that
platform.]
mma
Re: submission of new Windows rwlock code
Posted by Bill Stoddard <bi...@wstoddard.com>.
Marc M. Adkins wrote:
>I've re-coded the Windows rwlock based on the OS/2 algorithm implemented by
>Brian Havard. My test program doesn't show starvation with this algorithm.
>I'm assuming that the code is stable and works correctly on OS/2, and it's
>essentially the same code here, plus it passes all the tests I know how to
>do so I'm submitting the code for review.
>
>Somewhat to my surprise the performance test program that comes with APR
>seems to show an increase in speed of 30% - 50%. Possibly because the old
>code had two mutex waits for a read lock and the new code has one.
>
>I was initially surprised because the new code has tests on return values
>and an extra level of subroutine calling not present in the old code. Not
>to mention additional functionality: tryrdlock and trywrlock are both
>working now and starvation should be prevented. When does more
>functionality ever mean faster?
>
>I'm attaching the two changed files, which were essentially rewritten. So
>far as I can tell, the 2.1 code is still the same in CVS, so just replacing
>the files in their entirety should be sufficient. I can do diffs if that is
>better. I don't personally have CVS write access.
>
>mma
>
>
This definitely looks better based on the part I have reviewed. It
doesn't appear to me that the old code will ever allow multiple readers.
+1 with some coding style cleanups (which I'll do if I commit this code
tomorrow).
Bill
submission of new Windows rwlock code
Posted by "Marc M. Adkins" <mm...@Doorways.org>.
I've re-coded the Windows rwlock based on the OS/2 algorithm implemented by
Brian Havard. My test program doesn't show starvation with this algorithm.
I'm assuming that the code is stable and works correctly on OS/2, and it's
essentially the same code here, plus it passes all the tests I know how to
do so I'm submitting the code for review.
Somewhat to my surprise the performance test program that comes with APR
seems to show an increase in speed of 30% - 50%. Possibly because the old
code had two mutex waits for a read lock and the new code has one.
I was initially surprised because the new code has tests on return values
and an extra level of subroutine calling not present in the old code. Not
to mention additional functionality: tryrdlock and trywrlock are both
working now and starvation should be prevented. When does more
functionality ever mean faster?
I'm attaching the two changed files, which were essentially rewritten. So
far as I can tell, the 2.1 code is still the same in CVS, so just replacing
the files in their entirety should be sufficient. I can do diffs if that is
better. I don't personally have CVS write access.
mma
RE: read/write lockout
Posted by "Marc M. Adkins" <mm...@Doorways.org>.
> On Sunday, June 15, 2003, at 11:14 PM, Marc M. Adkins wrote:
> > Hmmm...does this mean that the APR read/write locks are supposed to
> > avoid
> > writer starvation? Should the Windows code be fixed?
>
> I think so, we should try to prevent writer starvation.
I'll take a look at the relevant Windows code (and the OS/2 example
mentioned earlier on this list) and try to generate a patch. If there's
someone more qualified who's going to do this, please let me know, I can
spend the time elsewise.
mma
Re: read/write lockout
Posted by Aaron Bannert <aa...@clove.org>.
On Sunday, June 15, 2003, at 11:14 PM, Marc M. Adkins wrote:
> Hmmm...does this mean that the APR read/write locks are supposed to
> avoid
> writer starvation? Should the Windows code be fixed?
I think so, we should try to prevent writer starvation.
-aaron
RE: read/write lockout
Posted by "Marc M. Adkins" <mm...@Doorways.org>.
> >I have code that uses a rwlock, a mutex, a condition, and an
> atomic variable
> >to provide something approaching fairness (on W2K, I haven't
> gotten around
> >to testing this on Linux yet). I can post it if anyone is interested.
>
> The OS/2 implementation (locks/os2/thread_rwlock.c) I wrote also avoids
> writer starvation in that it won't allow any new reader locks while a
> writer is waiting. It uses 1 mutex, 1 event semaphore. It should translate
> to Win32 quite easily. If you can spot any holes in my logic,
> please let me
> know :)
Hmmm...does this mean that the APR read/write locks are supposed to avoid
writer starvation? Should the Windows code be fixed?
mma
RE: read/write lockout
Posted by Brian Havard <br...@kheldar.apana.org.au>.
On Sun, 15 Jun 2003 12:08:55 -0700, Marc M. Adkins wrote:
>I have code that uses a rwlock, a mutex, a condition, and an atomic variable
>to provide something approaching fairness (on W2K, I haven't gotten around
>to testing this on Linux yet). I can post it if anyone is interested.
The OS/2 implementation (locks/os2/thread_rwlock.c) I wrote also avoids
writer starvation in that it won't allow any new reader locks while a
writer is waiting. It uses 1 mutex, 1 event semaphore. It should translate
to Win32 quite easily. If you can spot any holes in my logic, please let me
know :)
>> -----Original Message-----
>> From: Marc M. Adkins [mailto:mmadki@Doorways.org]
>> Sent: Thursday, June 12, 2003 4:30 PM
>> To: dev@apr.apache.org
>> Subject: read/write lockout
>>
>>
>> On W2K, read/write locks can result in writer starvation. If there are a
>> lot of readers a writer may never get a chance to lock at all.
>> I'm assuming
>> that 'fairness' in this sense is simply not guaranteed by APR. I was
>> wondering if anyone else had run up against this and how they solved it.
--
______________________________________________________________________________
| Brian Havard | "He is not the messiah! |
| brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
------------------------------------------------------------------------------
RE: read/write lockout
Posted by "Marc M. Adkins" <mm...@Doorways.org>.
I have code that uses a rwlock, a mutex, a condition, and an atomic variable
to provide something approaching fairness (on W2K, I haven't gotten around
to testing this on Linux yet). I can post it if anyone is interested.
mma
> -----Original Message-----
> From: Marc M. Adkins [mailto:mmadki@Doorways.org]
> Sent: Thursday, June 12, 2003 4:30 PM
> To: dev@apr.apache.org
> Subject: read/write lockout
>
>
> On W2K, read/write locks can result in writer starvation. If there are a
> lot of readers a writer may never get a chance to lock at all.
> I'm assuming
> that 'fairness' in this sense is simply not guaranteed by APR. I was
> wondering if anyone else had run up against this and how they solved it.
>
> mma
>
>
read/write lockout
Posted by "Marc M. Adkins" <mm...@Doorways.org>.
On W2K, read/write locks can result in writer starvation. If there are a
lot of readers a writer may never get a chance to lock at all. I'm assuming
that 'fairness' in this sense is simply not guaranteed by APR. I was
wondering if anyone else had run up against this and how they solved it.
mma