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