GPL Thread Manager 
Author Message
 GPL Thread Manager


<snip>

Quote:
> I am releasing the alpha version of the Thread Manager under GPL.  

1. What does it do? Why?

2. Why is it so complex?

3. How much constructive criticism do you want?

--
 Randy Goodhew
 ---[ eQ ]---



Wed, 09 Nov 2005 23:08:06 GMT  
 GPL Thread Manager
Randy,

Good to hear from you.

1.  It is a thread manager that allows developers to track threaded
procedures.  Also, a developer can allow procedures to be "queued" for later
processing.  These queued items are persisted if the application is shutdown
and reinstated when the application is started again.  This small project
has multiple purposes.
        a. Help developers here and myself to learn the best practices when
it comes to "Class" programming in Clarion
        b. Provide a mechanism for developers to track running threads and
to persist queued threads
        c. Allow a dynamic means to load DLL's at runtime without hard
linking in the libraries (something that I have done in the past, but I
noticed it has been a question that is frequently asked on the newsgroups -
this project shows the how-to's using loadlibrary, getprocaddress, etc.)
        d. At least with some of my projects, I need a way to provide
overriding the applications procedures.  Especially in one vertical
market...  I would provide a "custom.DLL" that may have a customized check
writer, Balance Sheet, or posting routine.  So this object would check the
CUSTOM.DLL first and if it receives a valid handle to custom.dll and the
requested procedure, it would run the customized procedure.  Otherwise it
would fall back to the applications procedure.

2.  As far as the complexity goes, I wanted to provide several features for
the developer.  If there is a better way to provide the functionality listed
as completed or "todo", please let me know and I will adjust the coding
where appropriate.  One item that may be over complex is the passed
parameters.  I felt inside of passing a zillion parameters that it would be
better handled by a group.  This could possibly be changed by:
        a. Allowing the developer to add a new procedure to the queue:
        b. Set the properties such as "started", queued/quedate/time and
par1, par2, etc.
        c. Telling the object to "Run or Persist(queue)" the item
        To further consider this:

            vdiTMx.Started = True        !A property
            vdiTMx.Par1 = 'My First Parameter'
            vdiTMx.Queued = True
            vdiTMx.QueDate = UserSelectedDate
            vdiTMx.QueTime = UserSelectedTime
            vdiTMx.Run()        !Tell it to save the item (which in this
example would queue the item until the specified date/time occurs)
                OR

queueing

3.  Send as much "constructive" criticism as necessary.  This is an "open"
project meaning two things:  Firstly, as a community, I and others would
love to learn from the "gurus" here (like yourself).  Secondly, to provide a
full featured, class based thread manager for everyone to use and enhance.
So please critize all you want.  I promise not to take it personally <g>.

Take care and I look forward to hearing from you!

Ben Kim

P.S. One item that I have not implemented in the examples is this:

1.  Define the class object in a base data dll
2.  Use the class object in the main executable
3.  Use the class object in other application DLL's that are not linked to
the main executable but have a reference to the base data dll.  This will
allow even dynamically loaded dll's to reference the "main" executable
reference to the base data dll's TM object and load/start procedures using
the same object.

I do have questions about proper instanitation and disposal of the object.


Quote:


> <snip>
> > I am releasing the alpha version of the Thread Manager under GPL.

> 1. What does it do? Why?

> 2. Why is it so complex?

> 3. How much constructive criticism do you want?

> --
>  Randy Goodhew
>  ---[ eQ ]---



Thu, 10 Nov 2005 21:07:00 GMT  
 GPL Thread Manager
Email to you bouncing. Want to put this up at CWICWEB. Ok?

Steve Parker

--------------------------------------------------
kb and download center at:
     www.par2.com
KB: http://www.par2.com/cws/c5launch.dll/FAQS/THEFAQS.exe.0
--------------------------------------------------

"The improbable, we do. The impossible takes a bit longer."



Fri, 11 Nov 2005 00:13:10 GMT  
 GPL Thread Manager
Steve,

Have you had an opportuntity to review the code?  I would appreciate any
suggestions, feature request or enhancements...

This class is freely distributable (not withstanding the one request that I
have and that is to share any enhancements and bug fixes!) and of course you
may upload it to your server.  However, as it stands it is not complete.
Do you want to wait a little while until it is at least feature complete and
bug free(is there such a thing?)...

Take care!

Ben Kim



Fri, 11 Nov 2005 03:52:37 GMT  
 GPL Thread Manager
I use few of the items on CWICWEB but I try to have what
look like the very best of freeware for Clarion up there.

I'll wait, if you'll send it on directly to me.

--

Steve Parker

--------------------------------------------------
kb and download center at:
     www.par2.com
KB: http://www.par2.com/cws/c5launch.dll/FAQS/THEFAQS.exe.0
--------------------------------------------------

"The improbable, we do. The impossible takes a bit longer."



Quote:
> Steve,

> Have you had an opportuntity to review the code?  I would appreciate any
> suggestions, feature request or enhancements...

> This class is freely distributable (not withstanding the one request that
I
> have and that is to share any enhancements and bug fixes!) and of course
you
> may upload it to your server.  However, as it stands it is not complete.
> Do you want to wait a little while until it is at least feature complete
and
> bug free(is there such a thing?)...

> Take care!

> Ben Kim



Fri, 11 Nov 2005 04:33:12 GMT  
 GPL Thread Manager
Inc.),

Quote:
> I am releasing the alpha version of the Thread Manager under GPL.

Why the GPL rather than, say, the LGPL? It's a while since I read the
licenses but isn't there the possibility that any software using a GPL
component is considered to come under the GPL as a consequence?

Dave

Dave Harms

Looking for C6 EA compatible products?
http://www.clarionmag.com/cmag/products.html?catid=163&subcatid=168

In-depth Clarion articles, news, tips & tricks
Plus the Clarion Online Archives!
Clarion Magazine: http://www.clarionmag.com



Fri, 11 Nov 2005 18:10:53 GMT  
 GPL Thread Manager
Dave,

If this is so, then I must restate my intentions.  This is a "free" to use
component.  However, I "request" that any changes, enhancements, bug fixes,
etc. be submitted back to me so I can upload the changes to a site where all
interested clarion developers have access to download.

Ben


Quote:
> Inc.),

> > I am releasing the alpha version of the Thread Manager under GPL.

> Why the GPL rather than, say, the LGPL? It's a while since I read the
> licenses but isn't there the possibility that any software using a GPL
> component is considered to come under the GPL as a consequence?

> Dave

> Dave Harms

> Looking for C6 EA compatible products?
> http://www.clarionmag.com/cmag/products.html?catid=163&subcatid=168

> In-depth Clarion articles, news, tips & tricks
> Plus the Clarion Online Archives!
> Clarion Magazine: http://www.clarionmag.com



Fri, 11 Nov 2005 23:44:53 GMT  
 GPL Thread Manager
Ben,

Quote:
> If this is so, then I must restate my intentions.  This is a "free" to use
> component.

Okay, it was the GPL reference that caught my attention. There are lots of
open source licenses out there (even one at ClarionMag -
http://www.clarionmag.com/cmag/dospl.html) and they have varying meanings.
But it sounds like you're not putting it under a specific license at this
point - is that correct?

Dave

Dave Harms

Looking for C6 EA compatible products?
http://www.clarionmag.com/cmag/products.html?catid=163&subcatid=168

In-depth Clarion articles, news, tips & tricks
Plus the Clarion Online Archives!
Clarion Magazine: http://www.clarionmag.com



Fri, 11 Nov 2005 20:12:26 GMT  
 GPL Thread Manager
Ben,

The following is CONSTRUCTIVE CRITICISM only. <grin>
NOTE: Clarion is a hybrid OOP language, like C++. So,
you are under no obligation to use pure OOP or pure
procedural programming techniques. You can mix and match
as you see fit. But, let's not over look the benefits of
OOP and let's assume OOP is beneficial.


Quote:

> Randy,

> Good to hear from you.

> 1.  It is a thread manager that allows developers to track threaded
> procedures.  Also, a developer can allow procedures to be "queued" for later
> processing.  These queued items are persisted if the application is shutdown
> and reinstated when the application is started again.  This small project
> has multiple purposes.
>         a. Help developers here and myself to learn the best practices when
> it comes to "Class" programming in Clarion
>         b. Provide a mechanism for developers to track running threads and
> to persist queued threads
>         c. Allow a dynamic means to load DLL's at runtime without hard
> linking in the libraries (something that I have done in the past, but I
> noticed it has been a question that is frequently asked on the newsgroups -
> this project shows the how-to's using loadlibrary, getprocaddress, etc.)
>         d. At least with some of my projects, I need a way to provide
> overriding the applications procedures.  Especially in one vertical
> market...  I would provide a "custom.DLL" that may have a customized check
> writer, Balance Sheet, or posting routine.  So this object would check the
> CUSTOM.DLL first and if it receives a valid handle to custom.dll and the
> requested procedure, it would run the customized procedure.  Otherwise it
> would fall back to the applications procedure.

My first question was loaded. Your reply says what I feared:

"My Class does this and this and this and this."

Good Class design should start with a simple and single theme. It should
be intended to do one thing or a modest collection of tightly related
things, very well, very simply, and very efficiently.

It looks like your Class is intended to do many things, its like a
mini application rather than single functional Class. You
wouldn't/shouldn't
design an entire application this way - Would you?

I suggest you break-up this big Class in to separate functionally
consistent Classes. These classes may be functionally related through
common sub-classes or even through derived inheritance (a lofty goal
indeed).

Besides, if you break up this thing in to smaller parts they will be
easier to manage, make more sense to the end user, and allow you to
use divide and conquer techniques to control the complexity.

- Show quoted text -

Quote:
> 2.  As far as the complexity goes, I wanted to provide several features for
> the developer.  If there is a better way to provide the functionality listed
> as completed or "todo", please let me know and I will adjust the coding
> where appropriate.  One item that may be over complex is the passed
> parameters.  I felt inside of passing a zillion parameters that it would be
> better handled by a group.  This could possibly be changed by:
>         a. Allowing the developer to add a new procedure to the queue:
>         b. Set the properties such as "started", queued/quedate/time and
> par1, par2, etc.
>         c. Telling the object to "Run or Persist(queue)" the item
>         To further consider this:

>             vdiTMx.Started = True        !A property
>             vdiTMx.Par1 = 'My First Parameter'
>             vdiTMx.Queued = True
>             vdiTMx.QueDate = UserSelectedDate
>             vdiTMx.QueTime = UserSelectedTime
>             vdiTMx.Run()        !Tell it to save the item (which in this
> example would queue the item until the specified date/time occurs)
>                 OR

> queueing

I see many opportunities in you code to improve and simplify.
The biggest problems I see are with your use of data:

a. You have Global Data in your Include file!
OOP uses a concept called Encapsulation to bind together data and code
in to meaningful units called Objects. A basic tenet of OOP is that all
data should belong __exclusively__ to its own object.

b. You have Module Static in your "MEMBER" code file.
Once again this is un-encapsulated data. Unless their
is strong evidence or a compelling reason to the
contrary, look at encapsulating this data.

c. It appears that you are directly accessing the data elements
within your Class (I'm not entirely sure of your intended usage).
Don't! The Properties (data) of a Class should only be accessed
by the Methods of the Class - again, a standard tenet of OOP.
You will lose control of your data and introduce more complexity
if you allow this to happen.

d. Are you "passing" information between Methods and/or the other
components of your application by directly accessing Properties?
Don't! Use "accessor" methods to carefully control the setting/getting
of Class owned data.

e. Reduce data complexity. There appears to be too many Properties and
it is hard to visualize exactly what goes where, how to "speak" to the
Class, and what the consequences are for using the data.

f. Understand the concept of OOP "Messaging".
Objects should only communicate through messaging, i.e. parameters,
returns values, and events (a Clarion concept).
IMNSHO, the concept of OOP Messaging is a glaring omission in the
standard Clarion docs.

Quote:
> 3.  Send as much "constructive" criticism as necessary.  This is an "open"
> project meaning two things:  Firstly, as a community, I and others would
> love to learn from the "gurus" here (like yourself).  Secondly, to provide a
> full featured, class based thread manager for everyone to use and enhance.
> So please critize all you want.  I promise not to take it personally <g>.

Aim toward embracing the best practices of OOP and strive to do one
thing
very, very well. Then add another Class.

Quote:
> Ben Kim

> P.S. One item that I have not implemented in the examples is this:

> 1.  Define the class object in a base data dll
> 2.  Use the class object in the main executable
> 3.  Use the class object in other application DLL's that are not linked to
> the main executable but have a reference to the base data dll.  This will
> allow even dynamically loaded dll's to reference the "main" executable
> reference to the base data dll's TM object and load/start procedures using
> the same object.

> I do have questions about proper instanitation and disposal of the object.

Ya see! Your Class is running head long in to complexity. <grin>

K.I.S.M.E.T. - Keep It Simple, Make Everything Tight.

This should get you thinking. Class dismissed... <grin>

- Show quoted text -

Quote:



> > <snip>
> > > I am releasing the alpha version of the Thread Manager under GPL.

> > 1. What does it do? Why?

> > 2. Why is it so complex?

> > 3. How much constructive criticism do you want?

> > --
> >  Randy Goodhew
> >  ---[ eQ ]---

--
 Randy Goodhew
 ---[ eQ ]---


Sat, 12 Nov 2005 02:02:22 GMT  
 GPL Thread Manager
That is correct Dave.  Anyone may use this class in ANY application.  That
is with the understanding that any enhancements/bug fixes are returned to me
for redistribution to other programmers here.  Currently I am in the process
of revising many areas of the class due to some misunderstandings I had of
Clarion OOP and thankfully pointed out by Randy Goodhew.  I will repost a
"new" copy of the class when I have a few issues addressed (such as
complexity and use of Global data)...  As Randy pointed out, the class is
overly complicated and needs to be split somehow into smaller more
understandable sub-classes...

Perhaps I will write an article for C-Mag about my adventures into OOP
programming and thread management in C5.5.

Take care!

Ben Kim


Quote:
> Ben,

> > If this is so, then I must restate my intentions.  This is a "free" to
use
> > component.

> Okay, it was the GPL reference that caught my attention. There are lots of
> open source licenses out there (even one at ClarionMag -
> http://www.clarionmag.com/cmag/dospl.html) and they have varying meanings.
> But it sounds like you're not putting it under a specific license at this
> point - is that correct?

> Dave

> Dave Harms

> Looking for C6 EA compatible products?
> http://www.clarionmag.com/cmag/products.html?catid=163&subcatid=168

> In-depth Clarion articles, news, tips & tricks
> Plus the Clarion Online Archives!
> Clarion Magazine: http://www.clarionmag.com



Sat, 12 Nov 2005 20:07:15 GMT  
 GPL Thread Manager
Randy,

Thank you for the insightful input.  Let me take your comments point by
point.

1.  Break the class down into smaller classes - I assume you mean worker
classes that communicate with the base thread manager class.  So would the
following illustrate what your comment was regarding?
        Thread Manager base class
            Construct
            Destruct
            Init
            Kill
            RunProc
            EndProc
            EndAllProc
            SuspendProc
            ResumeProc
            CheckCustom (check for custom library and procedure - called by
runproc)

        Thread Manager Queue Extension class
            Inherits Thread Manager base class or do I "reference" the base
object?
            QueueCheck
            QueueKill
            QueueAllKill
            QueueSave
            QueueLoad

       Thread Manager Additional Features Extension class
            additional features/functionality

If this is not what you are speaking of, exactly how would you separate the
procedures in a more maintainable, understandable form?

2.  a. Global data in the include file:  I am investigating how to
appropriately define the data/properties.
    b. Module Static?  Where did you see that or what are you referring to?
    c/d. Direct access to data: I am working on Get/Set property methods to
fix this issue
    e. Data complexity:  How would I reduce the data complexity when trying
to achieve what this class was designed to address?
    f. OOP Messaging:  Can you point me to any documentation on this?  I
want to understand the "proper"/"best practices" when it comes to passing
information from class method to method.

3.  K.I.S.S.:  Absolutely, yet another reason why I posted the code for
everyone to review and comment.

Again, being new to Clarion OOP programming paradigm (I have used OOP "IE:
ABC" but not truly programmed OOP in Clarion before), please bear with me.
I am striving to truly grasp and understand the does and don'ts behind
Clarion OOP.

My order for Bruce's (CapeSoft) book is pending delivery (7 business days!
grr!).  How do I place a book order with you Randy?  Didn't you write a book
on Clarion programming some time ago?

Thanks again for the "lesson".

Ben Kim
Vertical Dimensions, Inc.

http://www.vdisoftware.com



Sat, 12 Nov 2005 22:57:47 GMT  
 GPL Thread Manager


Quote:

> Randy,

> Thank you for the insightful input.  Let me take your comments point by
> point.

> 1.  Break the class down into smaller classes - I assume you mean worker
> classes that communicate with the base thread manager class.  So would the
> following illustrate what your comment was regarding?
>         Thread Manager base class
>             Construct
>             Destruct
>             Init
>             Kill
>             RunProc
>             EndProc
>             EndAllProc
>             SuspendProc
>             ResumeProc
>             CheckCustom (check for custom library and procedure - called by
> runproc)

>         Thread Manager Queue Extension class
>             Inherits Thread Manager base class or do I "reference" the base
> object?
>             QueueCheck
>             QueueKill
>             QueueAllKill
>             QueueSave
>             QueueLoad

>        Thread Manager Additional Features Extension class
>             additional features/functionality

> If this is not what you are speaking of, exactly how would you separate the
> procedures in a more maintainable, understandable form?

Attached is a file named TUT16.TXT. This is the exact specification file
that
I wrote in 1995 _before_ I began coding a Thread Manager using the the
first
Beta Version of Clarion for Windows. What is interesting to note is that
these
specifications changed very little while I wrote the first version of
TUT.
Later, about CW Version 4.5, I rewrote TUT as a Class and the interface
was
almost exactly the same. ==[ Source Code not available. ]==

Notice that TUT only manages threads, nothing more - very simple.

Break your Class down in to single theme classes.
If you are going to add features in the future, consider separate
classes
or derived classes. Don't ask a Class to do more than a handful of
things.

Note: Don't assume that you always need a CONSTRUCT and a DESTRUCT, but
do use them wisely. Also, I can't remember when I last needed INIT
and KILL Methods. Don't assume that they are required.
Season to taste, not to excess.

Quote:
> 2.  a. Global data in the include file:  I am investigating how to
> appropriately define the data/properties.

Great.
I see a lot of comments on this NG about folks trying to "manage" Global
Data. It's easy to manage if you minimize Global data, don't use it as a
substitute for passing parameters, and encapsulate it in to Classes.
When
used sparingly and properly, global data will manage itself.

Quote:
>     b. Module Static?  Where did you see that or what are you referring to?

In your file named VDITM.CLW, you have the following data declarations
after the end of the MAP and before the first procedure:

l:FunRef            LONG, NAME('MyFunction')        !Reference to
MyFunction
l:RetVal            BYTE, AUTO                      !Generic return
value
l:Found             BYTE, AUTO                      !Generic true/false
flag
l:Loop              ULONG, AUTO                     !Generic loop
indexer
l:CurrentThread     LONG, AUTO
l:ThreadID          LONG, AUTO
l:RetFunVal         STRING(256)
l:cProID            CSTRING(257)
l:WinRef            &WINDOW
l:cDLLName          CSTRING(257)

The above data is Module Static, i.e. it is visible to every
procedure/method
in this Member and it is persistent (STATIC) for the life of the
application
session. If multiple instances of your Class (objects) exist at the same
time,
they will all use this same data.

Quote:
>     c/d. Direct access to data: I am working on Get/Set property methods to
> fix this issue

Great.
Keep it simple...

BTW, if you have spent any time with the Windows API, you'll notice a
lot
of "Get*" and "Set*" functions. You won't see any direct access to the
data these API functions use!

Quote:
>     e. Data complexity:  How would I reduce the data complexity when trying
> to achieve what this class was designed to address?

In my book I talk about "down-scoping", i.e. moving data down to the
lowest and most appropriate visibility (Scope). That's a start.

Quote:
>     f. OOP Messaging:  Can you point me to any documentation on this?  I
> want to understand the "proper"/"best practices" when it comes to passing
> information from class method to method.

Any good generic book on OOP will help.
I do talk about Messaging in the CLARION COMPANION.

In true OOP languages, like Smalltalk, all Objects are completely
independent and can only interact by communicating through
messages. All data is owned by its host Class and can only be
used by its own Methods.

In OOP, data is never directly shared among objects.
In OOP, data is never "reusable" - a common misconception on this NG.

Quote:
> 3.  K.I.S.S.:  Absolutely, yet another reason why I posted the code for
> everyone to review and comment.

Great.

Quote:
> Again, being new to Clarion OOP programming paradigm (I have used OOP "IE:
> ABC" but not truly programmed OOP in Clarion before), please bear with me.
> I am striving to truly grasp and understand the does and don'ts behind
> Clarion OOP.

Remember, Clarion is a hybrid OOP language. So, you can pick and choose
between procedural and OOP techniques as satisfies your trade-offs.

Quote:
> My order for Bruce's (CapeSoft) book is pending delivery (7 business days!
> grr!).  How do I place a book order with you Randy?  Didn't you write a book
> on Clarion programming some time ago?

I wrote the CLARION COMPANION in 1998 (CW Version 4.0) specifically for
Mitten Software. They own it. You can contact them at
  www.mittensoftware.com and see if it is still available.

--
 Randy Goodhew
 ---[ eQ ]---

[ Tut16.txt 11K ]
                             Thread Usage Tracker
                            ----------------------

  The Thread Usage Tracker module is a family of functions that can be
used to monitor thread usage, organize threads in to groups, control multiple
instances of a threaded procedure, post events to a single or multiple
threads, and to send signals between threads. This module uses advanced data
hiding techniques and there is no need for declaring Global data variables.

General:
--------
  1. Thread  
     The Thread Usage Tracker can accomodate up to 64 entries. Each entry
     must have a unique thread number, with no duplicates. A thread number
     must be in the legal range of 1 to 64.

  2. Type
     The Type parameter is used classify each entry and there may be
     duplicate Type values. If you wish to identify a particular procedure
     then use the ADDRESS function to set the Type value to the address of
     the desired START procedure. This Protected Mode address of a procedure
     (a LONG as selector:offset) will always be a unique number at
     run time.

  3. Signal
     The Signal value parameter is used to pass information between threads.
     There may be duplicate Signal values.

This module is supplied as a pre-compiled linkable library. The SmartLinking
features of the TopSpeed compiler will only link in those functions that are
actually used. All internal data are hidden and encapsulated. There is no
need to create GLOBAL data or to export data.
-----------------------------------------------------------------------------
           Copyright 1995 by Randy Goodhew. ALL RIGHTS RESERVED.
=============================================================================
  MAP PROTOTYPES:
  ---------------
  MODULE('TUT16.LIB')
    TUT_Add(LONG thread,<LONG type>,<LONG signal>),LONG
    TUT_Delete(<LONG thread>,<LONG type>),LONG
    TUT_Post(USHORT event,<LONG thread>,<LONG type>),LONG
    TUT_Signal(LONG signal,<LONG thread>,<LONG type>),LONG
    TUT_Count(<LONG type>,<LONG signal>),LONG
    TUT_Find(<LONG type>,<LONG signal>),LONG
    TUT_Extract(LONG thread,SHORT which),LONG    
    TUT_Status(),SHORT
  END

======================================================================
TUT_Add(thread[,type][,signal])
-------------------------------
  Description:
    Used to add an entry to the Thread Tracker and optionally to initialize
    the Type and Signal values for that entry.
  Parameters:
    thread  LONG; Value; Required: The Thread number, must be unique.
    type    LONG; Value; Optional: The Type, may be omitted or duplicate.
    signal  LONG; Value; Optional: The Signal, may ne omitted or duplicate.
  Return:
    0 = No add occurred; see TUT_StatusCode().
    1 = The entry was Added.
  Usage:
    1. TUT_Add(3)      Add Thread 3 to the Thread Tracker.
    2. TUT_Add(3,2)    Add Thread 3 and set Type to 2.
    3. TUT_Add(3,2,-1) Add Thread 3, set Type to 2, and set Signal to -1.
    4. TUT_Add(3,,-1)  Add Thread 3, omit Type, and set Signal to -1.
  TUT Status Codes:
    0 = No Error.
    1 = Thread parameter is out of bounds.
    3 = Thread entry already exists.
  Notes: Use this function to add an active Thread to the Tracker as soon
         as a Thread is successfuly STARTed, for example:
           thread# = START(MyProc,15000)
           IF thread# <> 0
             r = TUT_Add(thread#,ADDRESS(MyProc),-1)
           ELSE
             ! thread was not STARTed
           END
======================================================================
TUT_Delete([thread][,type])
---------------------------
  Description:
    Used to delete entires in the Thread Tracker.
  Parameters:
    thread  LONG; Value; Optional: Limit the delete to this Thread only.
    type    LONG; Value; Optional: Limit the deletes to this Type only.
  Return:
    LONG;  Returns the number of thread records that were deleted.
           A "0" Return value could have two meanings; 1) no entries
           were deleted, or 2) and error occured (see TUT_ErrorCode()).
  Usage:
    1. TUT_Delete(3)    Deletes the Entry for Thread 3.
    2. TUT_Delete(3,2)  Deletes the Entry for Thread 3 if it is Type 2.
    3. TUT_Delete(,2)   Deletes all entries that match Type 2.
    4. TUT_Delete()     Deletes all entries.
  TUT Error Codes:
    0 = No error.
    1 = Thread parameter is out of bounds.
    2 = Thread entry does not exist.
  Notes: Delete an existing entry in the Tracker as soon as the Thread is
         finished executing. Best used as the last line of code in a
         STARTed procedure, for example:

          r = TUT_Delete(THREAD())

======================================================================
TUT_Post(event[,thread][,type])
-------------------------------
  Description:
    Used to Post an Event to a particular Thread entry or to all entries
    of a particular Type.
  Parameters:
    event   LONG; Value; Required: A standard Clarion for Windows event.
    thread  LONG; Value; Optional: POST to this Thread number only.
    type    LONG; Value; Optional: POST to all Thread entries with this Type.
  Return:
    LONG;   Returns the number of thread entires that were posted.
  Usage:
    1. TUT_Post(EVENT:CloseWindow)     Posts the event to all threads.
    2. TUT_Post(EVENT:CloseWindow,3)   Posts the event to Thread 3.
    3. TUT_Post(EVENT:CloseWindow,3,2) Posts the event to Thread 3 if
                                       the Type is 2.
    4. TUT_Post(EVENT:CloseWindow,,2)  Posts the event to all Threads that
                                       are Type 2.
  TUT Error Codes;
    0 = No Error.
    1 = Thread parameter is out of bounds.
    2 = Thread entry does not exist.
  Notes: Allows for multiple event postings by group or procedure.
======================================================================
TUT_Signal(signal[,thread][,type])
----------------------------------
  Description:
    Used to set the Signal value on a particular Thread entry or on all
    entries of a particular Type.
  Parameters:
    signal  LONG; Value; Required: Set the value of this Signal.
    thread  LONG; Value; Optional: Set the Signal for this Thread entry only.
    type    LONG; Value; Optional: Set the Signal for all entries of this Type.
  Return:
    LONG;   Returns the number of thread records that were updated.
  Usage:
    1. TUT_Signal(-1)     Set Signal for all Entries.
    2. TUT_Signal(-1,3)   Set Signal for Thread 3 only.
    3. TUT_Signal(-1,3,2) Set Signal for Thread 3 if the type is 2.
    4. TUT_Signal(-1,,2)  Set Signal for all Entries that are type 2.
  TUT Error Codes:
    0 = No error.    
    1 = Thread parameter is out of bounds.
    2 = Thread entry does not exist.
  Notes: Can be used to signal a suspend and resume of a threads activity,
         notify the status of activity on a thread, or provide a semaphore
         for inter-thread signalling.
======================================================================
TUT_Count([type][,signal])
--------------------------
  Description:
    Count the number of Thread entries that match the parameter values.
  Parameters:
    type    LONG; Value; Optional: Count entries that match this Type value.
    signal  LONG; Value; Optional: Count entries that match this Signal value.
  Usage:
    1. TUT_Count(2)     Counts all Entries that are type 2.
    2. TUT_Count(,-1)   Counts all Entries with a Signal of -1.
    3. TUT_Count(2,-1)  Counts all Entries that are type 2 and Signal -1.
    4. TUT_Count()      Counts all of the Entries.
  Return:
    LONG; Gets the record count.
  TUT Error Codes:
    0 = No error.
  Notes: Usefull for limiting the number of thread instances of a particular
         procedure.
======================================================================
TUT_Find([type][,signal])
-------------------------
  Description:
    Find the thread entries that match the parameters values.
  Parameters:
    type    LONG; Value; Optional: Set the Find match to this value.
    signal  LONG; Value; Optional: Set the Signal match to this value.
  Return:
    LONG; Gets the Thread number.
  Usage:
    1. TUT_Find(2)     Find the first Entry with type 2.
    2. TUT_Find(2,-1)  Find the first Entry with type 2 and Signal -1.
    3. TUT_Find(,-1)   Find the first Entry where the Signal is -1.
    4. TUT_Find()      Find the next Thread number that matchs the
                       previously set parameters. A return value of 0
                       indicates that there are no more matching Entries.
  TUT Error Codes:
    0 = No error.
  Notes: This function is used to first set a match by Type and/or Signal
         value(s), then to get each Thread entry number that matches.
======================================================================
TUT_Verify(LONG thread,<LONG type>,<LONG signal>),SHORT
-------------------------------------------------------
  Description:
    Verify that a particular Thread entry exists and to optionally test its
    Type and/or Signal values.
  Parameters:
    thread  LONG; Value; Required: Verify this Thread entry is in Tracker.
    type    LONG; Value; Optional: Verify that Thread matches this Type.
    signal  LONG; Value; Optional: Verify that Signal matches this Signal.
  Return:
    LONG;   0 = false (not verfified) and 1 = true (verified).
  Usage:
    1. TUT_Verify(3)       Verify that Thread 3 is in the Thread Tracker.
    2  TUT_Verify(3,2)     Verify that Thread 3 is Type 2.
    3. TUT_Verify(3,2,-1)  Verify that Thread 3 is Type 2 and a Signal of -1.
    4. TUT_Verify(3,,-1)   Verify that Thread 3 has a Signal value of -1.
  TUT Error Codes:
    0 = No error.
    1 = Thread parameter is out of bounds.
    2 = Thread entry does not exist.
  Notes: Usefull to check both the Type and Signal of a Thread entry.
======================================================================
TUT_GetType(thread)
-------------------
  Description:
    Access function used to get the Type of
...

read more »



Sun, 13 Nov 2005 02:01:15 GMT  
 GPL Thread Manager
ADDENDUM:

The attached TUT16.TXT was a "First Draft" of the original specs!

The final draft combined TUT_GetType() and TUT_GetSignal() in to
a single TUT_Extract() that used a second parameter to indicate
whether to return the value of a type or signal (used an EQUATE).
TUT_Verify() was dropped and TUT_Count() was changed so that if
all three parameters were omitted, all threads in the Queue were
verified to exist, with automatic adds and deletes if needed.

When TUT was converted to a Class, only CONSTRUCT and DESTRUCT
methods were added to deal with the STATIC Queue.

--
 Randy Goodhew
 ---[ eQ ]---



Sun, 13 Nov 2005 03:03:45 GMT  
 GPL Thread Manager
Ben,

Quote:
> Perhaps I will write an article for C-Mag about my adventures into OOP
> programming and thread management in C5.5.

I'd be delighted! See your email.

Dave

Dave Harms

Looking for C6 EA compatible products?
http://www.clarionmag.com/cmag/products.html?catid=163&subcatid=168

In-depth Clarion articles, news, tips & tricks
Plus the Clarion Online Archives!
Clarion Magazine: http://www.clarionmag.com



Sun, 13 Nov 2005 04:11:40 GMT  
 
 [ 14 post ] 

 Relevant Pages 

1. the real lesson of the GPL thread

2. Put GPL/FSF Rants Here not in Doom thread

3. Put GPL/FSF Rants Here not in Doom thread

4. the real lesson of the GPL thread

5. Thread Manager advice wanted

6. Thread manager

7. Thread Manager ?? Report Templates

8. U-Beaut! **NEW** Thread Manager

9. Apple Thread manager for use with MacMETH

10. Threads creating threads creating threads...

11. thread, threading, mutex modules and non-threading interpreters

12. [OT} How to un-GPL parts of a GPL'd module.

 

 
Powered by phpBB® Forum Software