Is there really a bug with the callback API, or is the "bug" that people have problems doing multi-threaded programming properly?
polling has it's place. and in some places it simply can't be replaced by callbacks.
particularly when you have to build upon an architecture that has a lot of threading
issues already.. A lot of systems particularly bsd have subtile threading problems,
especially if you try and mix them with select.. and if you code need to be cross platform
it gets even more interesting. but that another issue and not one for the list..
what I am complaining about is that the current callback system is flawed. it
only provides you information on tokens that you already know about.. If your token
list needs to be updated, it is very easy to enter into a deadlock condition, or
miss a callback. this is bad design. I discovered this after only an afternoon of
working with the API. if you insist on a callback system (and its not no problem
with me, then you really need a callback that that will notify you of any changes
to the tokens, without you giving it a list.. it should notify you in the callback
of what token it is refering to.. further, the tokens should have some kind of of
unique identifier, maybe a refnum that you can use to track it's condition..
for now I have to use the MSCIsTokenMoved() API to check for things, but again this requires me to check for new tokens my listing them..
and about "cancelling callbacks?" it will fail if you try and cancel one that is in progress
at the time. the callback system should be able to cancel any further callbacks, even
if one is currently waiting on a semaphore/mutex..
Oh and Michael, I might say that you made a "bad assumption" if you think that I am
approaching this from a lack of experience, I have been there done that.
_______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.drizzle.com/mailman/listinfo/muscle
