httpd-test-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norman Tuttle <ntut...@photon.poly.edu>
Subject Use of apr_sleep() in Flood, and apr_psprintf
Date Mon, 17 Feb 2003 20:15:08 GMT
Just a brief introduction. We are using Flood as a backbone to create an
"engine" for a multi-platform load testing system with a GUI front end and
in a Websphere / SQL environment. I have been making modifications to
Flood, mostly running on a Win32 environment but also under Linux, to
perform our needed functionality. More will be said about the type of
functionality we are providing and what bug fixes and upgrades we can
provide to Flood in a future post. For now I focus on a few APR concerns.

It concerns me that Flood is using apr_sleep() to create delays which are
used as part of threads. Being familiar with the use of threads from a
graduate course, and having access to IBM documentation on DCE threads, I
note that their documentation cautions against the use of the sleep()
system function when using multithreaded packages. Not that sleep() is not
thread-compliant but that it will cause the current process to sleep and
not the thread. This means that all threads in the current process are not
being executed while the process is going to sleep. I don't think that
this is the desired behavior in Flood for when APR_HAS_THREADS because it
would mean that for those periods of time, Flood is not being involved in
load test (or any useful activity). I believe I have seen times when this
behavior is observed while running Flood. A website I was browsing
recently gave an example using POSIX threads, and cautioned not to use
sleep() because of this issue, recommending instead something like
oskit_pthread_sleep(), which is actually an extension to POSIX threads.
   Windows implementation of apr_sleep() is Sleep(); Linux uses a select()
with the last argument being non-zero. Don't know if the Windows Sleep is
executed as a hold on the process level but my Unix documentation for
select seems to indicate that it applies the wait on a process level.
Perhaps I am wrong and this is not an issue; but I was hoping that someone
with more of an operating system or multithreading background (or the
designers of the original code, etc.) would be able to shed light on
whether this is an issue or not (and if so, why not), and if it is an
issue, how we can code a bug fix or a valid solution.

   apr_psprintf() is another function used in Flood. I had a problem with
some of the formatting options while using this function, and some other
concerns, so I looked into the code and found a comment that some
assumptions were made. It seems that those assumptions involved an order
of operations which might not hold true in a multithreaded case.
Therefore, I reconstructed the functionality of apr_psprintf in such a way
as to not make the assumptions in the comments, by using a feature of a
function which it already calls, and used this new function locally (I
called it print_to_pool) without modifying the version of the apr. I
haven't seen the type of problems I was seeing earlier since I made this
switch. I can make this code available upon request.

-Norman Tuttle, Software Engineer Consultant for OpenDemand Systems
ntuttle@opendemand.com













Mime
View raw message