Hi Victor,
[EMAIL PROTECTED] wrote:
>
> On Thu, Jan 06, 2000 at 09:29:43AM +0000, Stuart Hughes wrote:
> > > How about
> > > rtl_proc_name_thread("name",thread)
> > >
> >
> > A good idea, but why not make it rtl_name_thread("name", thread). This
> > would be useful as if you had no /proc available, then the routine would
> > not attempt to add it to /proc, but it would still be possible to let
> > other rt threads inquire about this thread by name. So you could then
> > have stuff like
> >
> > thread_id = rtl_getthreadbyname("name")
> >
>
> Sure. Want to contribute a module?
>
I'm happy to help out, if I get the time I'll do it (but probably
(hopefully) someone will beat me to it :-)
> > Just a thought, but in any case as you suggest, let's not tie the name
> > to the /proc system.
> >
> >
> > >
> > > > " real " Pthreads.
> > >
> > > RTLinux pthreads are real.
> >
> > What is meant is clear, pthread implies POSIX threads, so therefore we
> > should only use the term pthread for calls that can be found in the
> > POSIX 1003.1c standard (and match exactly the function prototypes and
> > behavior).
>
> I know. But IMHO, the POSIX pthread standards committee has invited
> additions and variations to the standard by suggesting the _np suffix.
> They have done so for a good reason, the standard is not complete
> although the core is very useful. Since Sun, HP, Compaq, and others
> provide pthreads libraries with either pthread_xxx_np or
> things like (compaqs) tis_xxx(pthread_t ... ), I don't think it is
> wrong for us to do the same.
>
> I'm not religious about this, and if people what to make sure that all
> calls
> pthread_xxxx_np
> also can be called
> rtl_thread_xxxx
> or something, then , why not?
I agree and point taken. I think the _np suffix is okay provided that
people using it really understand what it means regarding portability.
What is the forum/mechanism regarding trying to bring this stuff into
the POSIX standard ??
>
> > > > Note the fifo has a name like the task that appears in /proc/rtl/fifos
> > > > An arbitary fifo number will be used .
> > >
> > > I very much like the way we do it now with the posixio module.
> > > 1. if you want the raw interface, you use numbers
> > > 2. if you want the posix interface you use open("/dev/rftx").
> > >
> >
> > It would be nice to add a proper named fifo interface. By this I mean
> > do an
> >
> > id = rtl_fifo_named_create("my_fifo_name", size)
> >
> > The module would then find a free fifo, register the id against the name
> > and then return the id (file descriptor). This would mean that you
> > would not have to pre-plan which fifo number you are going to use.
>
> I was in favor of this, but now I think that that it simply repeats in
> a less portable form, open/read/write. That is, if you want raw fifos,
> use raw fifos. If you want fifos with names, use the posixio interface
The problem with the posixio in RTL is that you still have to ask for
/dev/rtfx, and the x refers to an actual number, so you are not really
much better off than the raw interface (aside from the more standard
semantics). What I'm hinting at is the need for dynamic association
between a name and an actual minor device number. This way we can use
abstract names such as "emergency_stop" or "data_stream" and not have it
fixed to a minor device number.
>
> > > Keep in mind
> > > (A) no user should have to pay a cost in program size, complexity, or
> > > performance for a "feature" she does not need.
> > > (B) the components should be as freestanding as possible and not
> > > have gratuitous interdependencies.
> >
> > Exactly, that is why POSIX support should be an optional module, like
> > any other A
> > API module interface, not part of the base layer.
>
> BTW: all of this is a discussion of things in the optional modules
> layers. But if people want a pure V1 API scheduler, I think that's
> fine too.
>
> Also, btw, when I figure out how to use cvs, I will put out a new
> version of the RTL V1 compatibilty code in V2. Please look at that
> and you will see that V1 really does map nicely to a subset of V2
> pthreads.
Regards, Stuart.
--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/
