On Wednesday 26 September 2001 03:23 pm, Justin Erenkrantz wrote: > On Wed, Sep 26, 2001 at 01:43:42PM -0700, Ryan Bloom wrote: > > You can keep saying to use the thread ID, but it won't work. Not all > > platforms use an int to reference a thread_id. We have a opaque > > data type for threads for a reason. At least two of our platforms today > > do not refer to thread_id's as ints, BeOS and Windows. Now, we may > > be able to get an int out of the platform, but we don't do it today. We > > should not force platforms to provide an int. This is what we did with > > processes, and it was wrong there, it will be wrong with threads too. > > > > If you want to use an int, it must be provided by the application using > > the buckets. In httpd's case, use the c->id. Create a function that > > allocates the correct size of an array, and just pass in c->id. DONE! > > Who said it was an int? I never said that anywhere. I was > specifically referring to apr_os_thread_t and the comparison function > apr_os_thread_equal. Both of these should be implemented per OS and > there is no assumption that it is an int or a directly comparable > anywhere in my suggestion. It can be a int, int*, my_thread* > - whatever. But, if apr_os_thread_equal does not compare the two > opaque structures correctly, then that is a broken function. > > (I notice that Win32 doesn't implement apr_os_thread_equal - why? > Does it not have the ability to compare two tids? Or, should we > be calling GetCurrentThreadID() instead? Perhaps we should call > both and store it in the apr_os_thread_t for Win32?) > > The key idea behind my pseudocode was that the uniqueness is > hidden within apr-util.
If it isn't an int, then the whole idea is useless unless we use a hash. A hash is the wrong solution, because there is an absolute cap to the number of slots we need in the table of freelists. Also, each thread has a unique identifier already, so we can easily just use a simple array. It just so happens that in this case, it is easy to use an httpd assigned unique identifier. That is re-using a variable, it isn't breaking an abstraction. > > There is no reason for either a linked-list or hashtable. This should be > > a simple array. We are talking about 1 pointer per slot in the array, > > allocated once. Assume a 64-bit platform, for a worst case scenerio, and > > 2000 threads per process, and you have 1600 bytes for the static> > > > allocation. > > No, I don't believe it should be an array because you are requiring > the arrays to be created by the user of the buckets. I think that > is completely bogus. The user of the bucket code shouldn't care > diddly-squat about the fact that the bucket code implements a > freelist. The fact that we implement any type of freelist > shouldn't be exposed externally outside of the bucket code - it > should remain hidden. I think the external API to the buckets > must remain the same. Please read all of my messages. I have said since the beginning that there would be an API, apr_bucket_list_init (bad name, but nobody ever lets me name things), which would allocate the array. If you want to allocate a hash table, you will need the same general function, or you will have an if in every allocate function, which is just broken. > And, for obvious reasons (i.e. the bucket code has no idea how > many threads are active at one time), it can't use a simple > array. Therefore, a linked-list or hashtable are required so > that it can have grow enough slots for all active threads that > request buckets. > > I think you are blurring the distinction between APR and httpd. > Yes, you could create an array full of opaque data structures in > httpd and pass that in to the bucket functions - I am merely > stating that I believe that is broken API. My suggestion was > just one way to handle the case without having the freelist > API exposed to the outside world. That requires an external > form of identifying the caller - which is what I believe the > apr_os_thread_t provides. Justin, go back and read the messages I have written please. I have asked to add a single function call to httpd. That is a setup function for the buckets. I am not talking about allocating any data in httpd at all. > I'm beginning to wonder whether we even need per-thread > freelists at all. Our pools don't have them. Take this > conversation and extend it to pools (i.e. when you create > a pool, you pass in a caller-defined freelist) seems even > more disturbing. -- justin I don't even know how to respond to this. Just about everybody on this list has said that a caller defined freelist is incorrect. Ryan ______________________________________________________________ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --------------------------------------------------------------
