On Thu, 2006-08-24 at 16:31 +0200, SF Markus Elfring wrote: > How do you think about to add a (convenience) procedure to keep such a > job manager running in a new pre-emptive thread? > http://felix.sourceforge.net/doc/rtl/doxygen/html/classflx_1_1pthread_1_1worker__fifo.html
I'm not sure what you mean. It's useful in these discussions to distinguish Felix code and C++ RTL library code. Note Felix code also allows arbitrary embedded C++. I'm not sure there is a Felix binding to create a worker_fifo/job queue/ thread pool thing at the moment .. it is easy enough to make one though. [at least i think it is] > Would you like to support that work or command objects can be sent to a > target thread like that can be done with TCL scripts by the function > "thread::send"? > http://tcl.cvs.sourceforge.net/*checkout*/tcl/thread/doc/html/thread.html#10 That's already supported .. otherwise how would the job pool be used? :) The schedulable entities are classes derived from 'worker_task'. However you can't send these jobs to a particular thread, only put them on a particular queue .. unless of course the pool only contains one thread. Most of the Felix system stuff only uses one thread. > How do you think about to provide a service that can only execute a > single task? Again, I'm not quite sure what you mean. You can spawn a pthread in Felix to do one task .. this has nothing to do with the thread pool stuff: Pthread::spawn_pthread { .. }; spawns a new Felix subsystem which executes the code in { .. } as the thread start routine of a new pthread (with some wrapping of course). At the moment each such spawned thread has an entirely new I/O system including its own private worker fifo: the garbage collector and lexical context is shared, however. It's not clear this is right: it is rather heavyweight, but it is a consequence of the driver design, related to the way asynchronous event handling interacts with the synchronous fibres (felix non-pre-emptive threads). > (Calls to thread-unsafe interfaces can be wrapped by it.) > Do you find my suggestion "class for function calls that are not thread > safe" useful? > http://groups.google.de/groups?threadm=OtKbb.127587%24mp.64498%40rwcrnsc51.ops.asp.att.net > http://groups.google.de/groups?threadm=34fu29F49rvasU1%40individual.net > http://groups.google.de/group/comp.programming.threads/browse_frm/thread/68c6f7f993578408 Not sure. Typically, it isn't just one function that is not re-entrant, there is a protocol requiring multiple calls which need to be made exclusively. Note Felix has a monitor object already .. it is in fact the implementation of a Felix pre-emptive channel :) The thing here is: Felix doesn't have any 'unsafe' functions. The whole system is fully re-entrant. The problem is with shared data, not the functions. For example the garbage collector is not thread safe. but there is a thread safe wrapper around the function calls which makes it thread safe .. this thread safe version of the collector is the standard one actually used. The unsafe one is kept, in case you have a sequential program and don't need any threads .. then the unsafe one can be used and will be faster. > > We'd need a use case before considering priorities, > > they don't make sense for any of the existing uses. > > > Priority Scheduling in TinyOS - A Case Study > http://www.cs.wustl.edu/~venkita/publications/class/tinyospriosched.pdf > > http://www.opengroup.org/onlinepubs/009695399/functions/pthread_setschedprio.html > http://en.wikipedia.org/wiki/Priority_inheritance What I mean is an actual requirement, not a design for one :) Clearly there is need for RT operating system support. BUt someone needs to come along and say "I want to do THIS specifically, how do I do it?" A generic class of such problems interests me: games. Another class of interest is GUI design. Most GUI are hopeless in this respect. > > It also isn't clear how prioritorisation would be > > supported on an OS that has no underlying support > > for RT operation. > > > > > Would you like to check for the symbols > "_POSIX_THREAD_PRIORITY_SCHEDULING", "_POSIX_THREAD_PRIO_INHERIT" and > "_POSIX_THREAD_PRIO_PROTECT"? The existence of a couple of hints doesn't make Posix capable of supporting RT programming. >From my man page: "The realtime scheduling policies !SCHED_RR! and !SCHED_FIFO! are available only to processes with superuser privileges." "schedparam Contain the scheduling parameters (essentially, the scheduling priority) for the thread." "This attribute is not significant if the scheduling policy is !SCHED_OTHER!; it only matters for the realtime policies !SCHED_RR! and !SCHED_FIFO!." which is of course fairly useless ;( -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Felix-language mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/felix-language
