This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Seeking Thread join / waitpid equivalent.


On Fri, Sep 03, 2004 at 11:15:45AM +0530, sandeep wrote:
> John Carter wrote:
> >I have just found this rather ugly code in the tftp_server.c
> >
> >So it kills the tftp server thread...
> >       cyg_thread_kill(server->thread_handle);
> >
> >whangs the priority of the thread it killed as high as possible.
> >       cyg_thread_set_priority(server->thread_handle, 0);
> >
> >Waits a random period for it to die
> >        cyg_thread_delay(1);  // Make sure it gets to die...

> how can you ensure that delay of 1 or N ticks that you put here, makes sure 
> that it gets to die???

> unless ofcourse you never have any thread in your 
> system that runs at priority 0 (highest) apart from these cases where you 
> boost priority of thread you killed, to 0.

You can't be sure.  It's unreliable code.  At the least, it places
spooky taboos (regarding thread priorities) on applications that need to
integrate the tftp server.

This was John's point, I think.

> for, if you have some threads running at priority 0 already, you need to 
> know the maximum no. of them that can be there in runqueue at any point of 
> time, that will be before your boosted-priority thread (considering round 
> robin scheduling and no-SMP) to find a sure-value that can be given to 
> above cyg_thread_delay.

> >Deletes the thread...
> >        if (cyg_thread_delete(server->thread_handle)) {
> >
> >If deleting the thread actually worked...
> >
> >            // Success shutting down the thread
> >Frees the memory associated with the thread..
> >            free(server);  // Give up memory
> >            return 1;
> >        }
> >Else ... we have a memory leak.

A replacing the 'if' with 'while' and bringing the
cyg_thread_delay inside would be better, I guess...

Still a clumsy hack which could be avoided if there were
a mechanism to wait on a thread's 'delete'-ability.


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]