Re: Use of apr_sleep() in Flood, and apr_psprintf

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Win32 is quite safe using Sleep() on one thread.  In fact, Sleep(0) will simply
let the process surrender the rest of the thread's current time slice.

Now, I agree this sounds like a huge concern, and not just for the flood app.
We would abosolutely like to address it in APR itself.

If you have more information to share about any platform and thread-sleep
behavior, please share it with the dev@apr.apache.org team so that it
benefits all apr applications, not simply the flood tool!

Bill

At 02:15 PM 2/17/2003, Norman Tuttle wrote:
>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