Re: cvs commit: apache-apr/include apr_file_io.h apr_network_io.h apr_thread_proc.h

[Ben Hyde <bh...@pobox.com>]

Ryan Bloom wrote:
 > ... For example, there are two falgs in the context types:
 > signal_safe and cancel_safe.

These are thread state, not "context" state.

Yes your right what you are calling contexts I'm calling pools.
That because we already have pools and I don't see any need for
another data type.  I might fall for a type hierarchy like
  context -- a thing a data type used to hold the state of some
             activity.
  > pool  -- a context which provides memory allocation and many
             data types that reside in that memory allocation.
  >> thread -- a pool that has stack and thread operations on it.



 > OK, I'm sorry.  I thought you were okay with this, but that was because I
 > read your messages wrong.  However, after looking back over your messages,
 > I really think we are advocating the same thing, but I haven't explained
 > what my end goal is, so I am going to try again.
 > 
 > First of all, contexts are not an opaque type.  They are the same on all
 > platforms, so the user can do whatever they want with them.



 > Second, what I am calling a context, I think you are calling a pool.  The
 > reason I am not calling it a pool, is that the pool code is already
 > written and tested, so I needed a new name.

Adding a few slots to the pool isn't as dangerous as introducing
unnecessay abstractions.

 > Okay, now with your pools, you want a link to the thread within the pool.
 > That link could be within the context (but I haven't create portable
 > threads yet, so it has to wait a little while).  

 > The context also allows
 > me to put user defined data in there.  That would be a perfect place for
 > any thread local data the program wants to define.

As i've said all APR types should provide a way for user defined data
to be hung off them.  All types exported from any API should.  It's
not unique to contexts.  It's a need for the root type of all system.

 > Contexts are not tied to threads, in fact if anything they are tied to
 > pools.  When I create a sub-context, I get a sub-pool at the same time.
 > There is nothing stopping me from getting a sub-context at any point in
 > thread execution.

You really haven't made the case that there is some 'entity' or
'object' or 'activity' that contexts are implementing which is
sufficently distinctive to warrent both a new type and worse a
type used in so many call sites.

 > It is in the plan, to have the context's determine how the apr functions
 > are to operate. ...

Who an object "operates" is the job of the object, not of the
root class of all objects.

 > I think the biggest difference, and correct me if I am wrong, is that you
 > want:
 > 
 > struct pool {
 >    /* what is in there now*/
 >    apr_thread_t thread_id;
 >    void *user_defined_data;
 >    int state_flags;
 >    ...   Anything else we determine we need later.
 > }

That's about right.

 > I am proposing:
 > 
 > struct pool {
 >    /* what is in there now */
 > }
 > 
 > struct context {
 >    struct pool pool;
 >    apr_thread_t thread_id;
 >    void *user_defined_data;
 >    int state_flags;
 >    ...   Anything else we determine we need later.
 > }

Yes, i agree that's what your proposing.

So we are discussing how to structure four fields.

1. "void *user_defined_data;" (or something with a little more 
design) should be in every struct.  It's nothing short
of rude and lazy to deny users a place to annotate your data 
structures. 

2. Your current examples of state flags belong in the the thread.
while a bit field in every struct is often a good idea if that
bit field is intended for users then it's part of the design of
user_defined_data, and if not it's not part of this discussion.

3. apr_thread_t thread_id  -- as I said before everybody needs
access to this.

4. apr_pool -- everybody needs access to this.

If both 3&4 are something that everybody need then there is
no reason no to put the thread into the pool.

 > If I am reading your notes correctly this time, I do not think we are very
 > far apart in implementation.  And the change from one to the other is
 > rather trivial.  

It's not trivial if this type is passed to the majority of operations
in the system.

 > What concerns me about your model, is that it pollutes
 > the pool type.  The pools would no longer be areas for memory space.  As
 > it is now, the pools are complicated and I am afraid adding new things to
 > them would only make them more complicated.

Some operations on pools need access to the thread the pool resides 
in so you have to have a pointer to the thread from the pool because
the block signals.

 > I also do not know how well Ralf's shared memory pools would interract
 > with regular pools in your model.

Ralf's pools "polute" or "supercharge" the pool data type.

Yes maybe you could design a system where the pool data type was
runtime or compile time selected.  But then you'd have to make
apr_alloc take a context and that would only prove my point that
your context is what we call a pool.

 > I am sorry that I mis-understood what you were saying earlier.  I really
 > thought and still think, that we are not very far apart from each other on
 > this topic.  However, I will not commit the rest of my changes until we
 > agree.

No problem, but I still remain convinced that these are not a good
idea.

Let me say that I've written large systems where the concept of a
"current context" was pervasive.  That I'm not arguing that such
systems don't have thier virtues.  I'm arguing that we already
have that "current context", the pool.  And that we then create
refinements on it, such as request_rec which have a pointer
to a pool.  That this design is good, that it is what we do,
and that to change it is unnecessary.  

 - ben

ps. We should find a way to take this back into new-httpd asap.


_______________________________________________________________________
Ryan Bloom		rbb@raleigh.ibm.com
4205 S Miami Blvd	
RTP, NC 27709		It's a beautiful sight to see good dancers 
			doing simple steps.  It's a painful sight to
			see beginners doing complicated patterns.