Re: Best way for start a rt-thread and wait

Giampaolo Bellini <[email protected]> 28 Jan 2005 09:44:14 +0100
Newsgroups gmane.linux.real-time.rtlinux.general
Organization DS4 Laser Technology
Message-ID <1106901854.2929.33.camel@Giampaolo>
> >  I need to start a rt-thread from user space, wait for the rt-thread to
> > complete his job and return a result in user space...
> > 
> >  in order to do this, I've created a rt-fifo and linked the user space
> > ioctl with the rtf_link_user_ioctl() function.
> > 
> > the problem is that sometimes my ioctl code put the user process to
> > sleep and never wake it up.
> > 
> > is there a best way to achieve this kind of functionality ?
> > 
> >
> not sure if its better or not - but an alternative would be to use the proc filesystem - here is a modified version of proc_start_stop.c that allows
> loading in an inactive state-starting via user-space task and then controlling the termination through the proc filesystem - to descide when to terminate you can monitor the status via the proc file aswell.
> 

 
Thanks a lot for your suggestion Hofrat... I'll take it for future
project!

In this case, however, I think it's not a good idea to proceed in that
way... I don't want to polling to know the rt-thread status... I want
the user process to sleep until data are ready... and the rt-thread to
wake it up... as it works for the 99% of the time, I think I'm missing
something... maybe to protect the my status variable with a semaphore.

The real fact is that actually I have not clear in my mind when kernel
threads/rt-threads/user_processes can be scheduled...

the kernel-side of the ioctl function, for example, can be scheduled in
the middle of it's code ? If I'm not wrong, this is not possible as
Linux Kernel is not preempted... but copying data to/from user space can
call schedule()...  so the ioctl can not be scheduled unless It calls
one of the function that may sleep. is this right ?

I've search many times to understand this point but I still have a lot
of doubt...

 thanks a lot,

    Giampaolo





_______________________________________________
Rtl mailing list
[email protected]
http://www2.fsmlabs.com/mailman/listinfo/rtl