[Uni-verse] possible maxbug

[Martin]

> Hi
> 
> > Well, when running on Intel Win32's (with fresh compile) I usually get a
> lot
> > of crashes. However after we made some changes so we control threads
> etc,
> > the server crashes less.
> 
> Changes to the server? or to the client? if you do something wrong with
> threds
> tou should be able to crash the client making the calls not the srevr it
> is
> connected to.

No changes.
Our library is thread-safe now.

 
> > Nope, it crashes here, but it is small dirty things in the code.
> > For example you get a run-time failure check (You use the variable
> 'drag'
> > without initializing it in some file at line 121...) and if you have a
> > debugger installed it will break the app.
> > This will halt/ throw (asm...3) an exception.
> 
> Hum that kind of thing should not break an app, it should give you
> awarning but
> not break the app... Debugg setting?

It does, my first guess is that you used some kind of asm 3 instruction to
halt on asserts etc.
I often do my own assert functions to get more information and more control.
No specific settings, I develop on several machines and get the same. Weird,
has to be an uglier thing than "not initialized" since I have never seen
that kind of error in any if my normal apps I develop.
Any way, the same happened on my Sony laptop and my custom stationary, even
with separate builds.

 
> > Well, I think most applications that will use verse are multithreaded.
> > But it isn't a big thing to implement on top of it (if you know about
> it),
> > but I certainly think a library like verse should be.
> 
> Iw ill bring it up with emil and see if we can figure something out.
> 
> > Mutexes, why? ... couldn't you do it with simple critical sections etc?
> Some
> > kind of read/write/access lock?
> 
> Mutex is a "Some kind of read/write/access lock". Problem is that it is
> not a
> standrard lib thing. Old verse used to be multithreaded and thats why it
> required pthread.lib and that made it much harder for people to build.
> we would
> like to avoid that. We also dont like the fact that we would be endorsing
> one
> tread api. Apparently linux is moving away form posix threads and who
> knows
> what ms does.


Mutex is thread-safing over process boundaries.
You could also use semaphores, critical sections etc for in-process control,
which I guess is what you should have.

So what I mean with "some kind of..." is a standard read-write lock using
for example critical sections.

But I understand your problems on Linux, since it has several possibilities.

/martin