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 [EMAIL PROTECTED]
