Hi Luca! Hi Jury!!!
I hope you had a nice Easter 9unfortunately here in Italy the weather
has been really bad :-( )
Btw, I'm really happy that Jury has done something working with OSLib
:-)))
> > > I use a table of 'process entries', i.e. an array of structures
> > > describing a process: base, size, stack, stack_size, CONTEXT, flags. The
> > > flags inform whether a process is active, whether this entry is
> > > occupied/valid and a kind of process: child/thread or
> > > parent/program. So inside my system I use PROCESS_IDs which
> > > reference into that table of processes, i.e. not CONTEXTs.
> > Ok... This is a fairly standard solution: shark is also using something
> > similar.
Yes... really the same thing!!! ;-)
> > > As I use
> > > context_create/delete I use a default killer procedure which uses my
> > > own delete_process function but (!) the killer function gots no
> > > parameters (opposite to the thread body) so I have to find my
> > > PROCESS_ID by looking through the table of processes for
> > > entry[i].ctx==ll_context_from().
> > Generally, a kernel has some variable storing the ID (in your case, an
> > integer indicating the PROCESS_ID) of the executing thread/task. This is
> > used by the scheduler (or by some other kernel subsystem) to perform
> > accounting, and is set by the scheduler when a context switch happens.
> > 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...).
> >
> > > The only thing I ask to add into OSLib
> > > is a function ll_context_create() with a support for killer routine
> > > with a parameter, so I can pass a process's ID as a parameter and
> > > simply do:
> > Ok, if you really want it (i.e., if you cannnot or don't want to use the
> > "current task" variable), I have no objection to such modification...
> > The only problem is that I have not much time to implement it right now
> > (I am busy with my job, and I'll be out of town for about 3 or 4 days in
> > the next week). Hence, I could do it only after the 1st of may. In the
> > meanwhile, if you want to provide a patch (it should not be that
> > difficult: I think that pushing the parameter on the task stack when
> > build it in ll_context_create would be enough), you are welcome.
What I think is:
the parameter in the context_create existed because we initially wanted
the possibility to create different threads that used the same thread
body with a different argument, as done for example in POSIX.
In the first versions of Hartik, the thread body was simply given into
the task_create together with its parameter. these informations were
then directly passed to ll_context_create(), so the parameter we passed
in the ll_contect_create was the same parameter passed to the thread.
In Hartik the killer function had no parameter because in any case the
kernel knows which is the task that is running at a given time, using a
global variable.
If I understood well, Juras is using the parameter to pass the
thread_ID, and then he maybe find eventual parameters into the thread
descriptor using that ID... then he would like to have the same
parameter in the killer function to kill the task... in that case, maybe
you do not need a killer function at all, just because you can use the
first function that has been called...
This is the code that is currently passed as body to the
ll_context_create (exec_shadow is the current running task; the abort
function is not used at all...
void task_create_stub(void *arg)
{
void *ret;
kern_after_dispatch(); // check for asynchronous cancellation and
signal delivering
ret = proc_table[exec_shadow].body(arg); // the call to the -real-
body
kern_cli();
task_makefree(ret); // internally calls ll_context_delete
ll_context_to(proc_table[exec_shadow].context);
}
At the end, I think that Juras proposal can be replaced without too much
effort with a global variable, also saving some ram space (you need an
initial push for every context, that is 4 bytes for every context (*),
whereas in the other case you need only one global variable to store the
executing task, that is maybe also needed when the kernel becomes a
little more complex).
(*)btw, who removes it from the stack if the killer function does not
return (as it should)?
Juras, what do you think about using a global variable to store the
executing task? (I did not received the whole thred you had with Luca)
bye
PJ
PS: I passed the g++ patch to Michael and Giacomo that are currently
working on that...
--
-----------------------------------------------------------------------
Paolo Gai - ReTiS Lab - PhD Student
Scuola Superiore S. Anna Tel : +39 050 883 451
Polo S. Anna Valdera Fax : +39 050 883 452
viale Rinaldo Piaggio 34 e-mail : pj...@ga...
56025 - Pontedera (PI) - ITALY home page : http://feanor.sssup.it/~pj
------------------------------------------------------------------------
Per favore non mandatemi allegati in Word o PowerPoint.
(Please avoid sending me Word or PowerPoint attachments.)
Si veda (See) http://www.fsf.org/philosophy/no-word-attachments.html
------------------------------------------------------------------------
|
