Re: Re[2]: [Oslib-devel] [Fwd: Re: OSLib, my os (SD-32 stormdos)]

[Paolo G. <pao...@ti...>]

> By the way, I want to warn once more that under VMWare
> (trial) I experienced problems running OSLib-based programmes... but with Bochs it's all ok.

I never tried with VMware.... I currently use a VMware 3.2 (registered)
version... I'll try when I'll have a few minutes...

> >> > The "standard solution" to your problem would be to use this variable
> >> > (since the killer executes in the context of the thread that is
> >> > terminating...).
> well, because I use the same functions for user threads, i.e. the
> threads created in user applications. So it would be convenient to
> have a thread ID as a parameter.

We can say "a parameter in general"... If you look at what happens in
the OS standards, POSIX Pthreads pass a void* as parameter, and they
give access to the thread ID using pthread_t... and if we think at a
portable application, pthread_t is an opaque type, and we cannot use it
to ask questions like "is this the thread 2 or the thread 3?"

> But now I think that we do not need to modify OSLib,
> I'll solve the problem another way. Let's not introduce any
> uncompatibility.

I mean, it's not incompatibility, because shark simply do not use the
killer function at all... simply my feeling is that forcing a thread to
receive its thread ID only by parameter do not solve the problem
(because it is unlikely that you'll pass the thread ID to all the
library functions that maybe will need it... and adding a function that
returns the pthread id of a task makes unuseful to pass it as
parameter...

[...]
> It's also a possible solution, thanks.

It's the one we currently use simply because I needed to:
- be able to kill a task if it has been asynchronously cancelled before
being executed
- be able to deliver pending signals when the task is scheduled the
first time
- know the return value of a thread, and basically the killer function
cannot read it (that's why I do not use it; an eventual parameter to
that function should be pushed on the stack before the killer return
value, so it doesn't work for the return value :-( )

> Now I decided to do the following: to use a default kernel-build-in
> killer function which calls an application defined killer body, and then
> using the global variable indicating the active task the function destroys the task
> with the CONTEXT...

Ok!!!

> Thanks for reply!

You're welcome!!!

PJ

-- 
Paolo Gai <pao...@ti...>