developer toolbox » harbour

čitanjem mailing liste harbour-a sam dosta toga zabilježio pa ću to sada ponovo proći pi postirati najinteresantnije

harbour MT¶

Re: [Harbour] Multithreading support in Harbour Sri 04 Nov 2009 13:08:33

From:     druzus@acn.waw.pl
To:     harbour@harbour-project.org
Reply To:     harbour@harbour-project.org
Sender:     harbour-bounces@harbour-project.org
On Wed, 04 Nov 2009, Enrico Maria Giordano wrote:
> Dear friends, I'd like to know where to find informations about the
> current state of the Harbour support for multithreading and if it's
> stable enough to be used in the applications.
> Many thanks in advance.

Look at:
   doc/xhb-diff.txt: "MULTI THREAD SUPPORT" 

In Harbour MT mode is fully functional and AFAIK is production ready
without any known bugs except 4 document problems which has not been
addressed and maybe never will be because they are not strictly
necessary to create final applications:
   1. Tracelog is not MT safe. It's not a big problem for normal
      applications because this code is disabled in standard builds and
      enabled only on explicit user request during Harbour compilation
      to debug some Harbour internals so it's rather for developers only.
   2. PROFILLER cannot collect information for each thread separately.
      It's optional code disabled by default. Before we will touch it
      please think how it should work for MT programs.
   3. DEBUGGER: only main thread debugger can see the names of file wide
      STATICs and have information about line numbers with good break
      points. We should add code to share this information between threads.
   4. hb_threadQuitRequest() can be ignored by thread in some cases
      due to race condition. It may happen if thread will overwrite
      request send by caller simultaneously, f.e. by its own BREAK.
      I can resolve it but we can also leave it as is and document
      such behavior as expected or even remove this function. Killing
      other threads in such way is dangerous and can be used only
      for some simple situation. It's much safer when user uses his
      own mechanism to terminate treads in some safe for his code places.

Harbour PRG level API:

  hb_threadStart( [<nThreadAttrs> ,] <@sStart()> | <bStart> | <cStart> [, <params,...> ] ) -> <pThID>
  hb_threadSelf() -> <pThID> | NIL
  hb_threadId( [ <pThID> ] ) -> <nThNo>
  hb_threadJoin( <pThID> [, @<xRetCode> ] ) -> <lOK>
  hb_threadDetach( <pThID> ) -> <lOK>
* hb_threadQuitRequest( <pThID> ) -> <lOK>
  hb_threadTerminateAll() -> NIL
  hb_threadWaitForAll() -> NIL
  hb_threadWait( <pThID> | <apThID>, [ <nTimeOut> ] [, <lAll> ] ) => <nThInd> | <nThCount> | 0
  hb_threadOnce( @<onceControl> [, <bAction> ] ) -> <lFirstCall>
  hb_mutexCreate() -> <pMtx>
  hb_mutexLock( <pMtx> [, <nTimeOut> ] ) -> <lLocked>
  hb_mutexUnlock( <pMtx> ) -> <lOK>
  hb_mutexNotify( <pMtx> [, <xVal>] ) -> NIL
  hb_mutexNotifyAll( <pMtx> [, <xVal>] ) -> NIL
  hb_mutexSubscribe( <pMtx>, [ <nTimeOut> ] [, @<xSubscribed> ] ) -> <lSubscribed>
  hb_mutexSubscribeNow( <pMtx>, [ <nTimeOut> ] [, @<xSubscribed> ] ) -> <lSubscribed>

  * - this function call can be ignored by the destination thread in some
      cases. HVM does not guaranties that the QUIT signal will be always
      delivered.

xBase++ compatible functions and classes:
   ThreadID() -> <nID>
   ThreadObject() -> <oThread>
   ThreadWait( <aThreads>, <nTimeOut> ) -> <xResult>
   ThreadWaitAll( <aThreads>, <nTimeOut> ) -> <lAllJoind>

   Thread() -> <oThread>      // create thread object
   Signal() -> <oSignal>      // create signal object

   Harbour supports also SYNC methods and SYNC class method implementing
   original xBase++ behavior.

   It also supports xBase++ concept of moving workareas between threads
   using functions like dbRelease() and dbRequest().

In *tests/mt* you will find few simple test programs for MT mode.

Some of Harbour tools like hbmk2 or uhttpd[2] (examples/httpsrv,
/examples/uhttpd2) use extensively MT mode.

best regards,
Przemek

http://gitorious.bring.out.ba/harbour/harbour/trees/master/harbour/tests/mt

MT and GTWVG¶

Re: RE: [Harbour] Multithreading support in Harbour Sri 04 Nov 2009 14:44:51

From:     druzus@acn.waw.pl
To:     harbour@harbour-project.org
Reply To:     harbour@harbour-project.org
Sender:     harbour-bounces@harbour-project.org
On Wed, 04 Nov 2009, Horodyski Marek (PZUZ) wrote:

Hi,

> >From my experience, GTWIN is working in MT without problem.
> GTWVT / WVG for larger applications may hang the application (small
> examples GTWVG work flawlessly).

As I told you it's expected behavior and the problem is created by your own code.

In MS-Windows only thread which created window can process window messages so if you are suing GTWVT or GTWVG the main
thread should not be suspended or it will block other threads
which will execute 'inkey(0)' or sth similar. 

Just simply incoming keys can be processed only by thread which created GTWVT window.

It's documented MS-Windows behavior and programmers have to know about it because it effects all MS-Windows programs in
all languages using any type of interface. 

*Usually the easiest  solution is leaving thread owner to only process window messages and create other threads to make real job.*

In some situations library author can create hidden thread to
process window messages in the background and hide the problem
at least partially for PRG programmers. 

GTWVT is type of program where it can be done though one feature blocks it and it will be
necessary to disable it. It's HB_GTI_NOTIFIERBLOCK which cannot
work when messages are processed by non HVM thread.
When GTWIN is used then such hidden thread to process console
window messages is created by system.

best regards,
Przemek

workarea preprocesor¶

Re: [Harbour] Data Dictionary Support Uto 20 Okt 2009 12:41:32

From:     druzus@acn.waw.pl
To:     harbour@harbour-project.org
Reply To:     harbour@harbour-project.org
Sender:     harbour-bounces@harbour-project.org
On Tue, 20 Oct 2009, Alex Strickland wrote:

Hi,

> I was thinking of the following:
> 1. A compiler option to declare a data dictionary declaration so
> that statements of the form:
> workarea->fieldname
> could be validated.
> In the case where a DBF exists it could be used as a kind of
> "include" file, and there would need to be an alias mapping:
> WORKAREA "acc101.dbf" ALIAS accounts
> and:
> accounts->name
> would be validated, and:
> accounts->nane
> would cause a compile time error. As would:
> ackounts->name
> In the case where no dbf exists (perhaps a SQL database or the new
> "mem:" files), or it is not practical to read a dbf then some syntax
> like:
> WORKAREA accounts
> FIELD accounts->name
> FIELD accounts->address ...

You can make it yourself using PP:

   #ifndef FIELD_NAMESPACE_OFF
      /* declare WORKAREA1 fields */
      #xtranslate WORKAREA1-><!field!>    => ;;
                              #error WORKAREA1 does not have field: #<field>
      #xtranslate WORKAREA1->name         => WORKAREA1->( _FIELD->name )
      #xtranslate WORKAREA1->date         => WORKAREA1->( _FIELD->date )
   #endif

   proc main()
      ? workarea1->name
      ? workarea1->nane
      ? workarea1->date
   return

best regards,
Przemek

GTWVT¶

Re: [Harbour] hb_setTermCP() + GTWVT UNICODE vs non-UNICODE Čet 08 Okt 2009 21:15:01

From:     harbour.01@syenar.hu
To:     harbour@harbour-project.org
Reply To:     harbour@harbour-project.org
Sender:     harbour-bounces@harbour-project.org
>> hb_setTermCP() will mess up the keyboard input for national
>> chars when used in UNICODE builds, while it won't for non-UNICODE
>> builds. Tested with GTWVT.
>> The point here is not the "mess up" part, but rather that
>> app behavior is different in UNICODE and non-UNICODE builds.
>> This is most probably not right this way. (the culprit is
>> hb_setKeyCP() behavior)
>
> I do not understand what is the problem in your case but for sure
> above does not discribe GTWVT behvior.
> For both UNICODE and non UNICODE modes all you should use:
>
>   hb_setTermCP( <cTermCP>, <cHostCP> )
>
> where <cTermCP> is OS encoding and <cHostCP> is HVM encoding.
> When <cHostCP> is not given then _SET_CODEPAGE is used.
> The only one difference between UNICODE and non UNICODE mode
> is the fact that in UNICODE mode <cTermCP> is ignored and only
> <cHostCP> is significant but for user code it does not create
> any differences.

Yes, sorry, I mixed the cases, it's ignored in UNICODE and
not ignored in UNICODE as you say.

It means I have to manually adjust CP setup for each platform,
build type and active GT (even WINE, but that's probably not
Harbour's fault). GTWIN works differently than GTWVT, GTWVT works differently in UNICODE and non-UNICODE mode, and
things work a little bit differently with other GTs. Things will be a bit more complicated on Windows, after my app switched
to ISO CP from DOS.

Now I had to drop hb_setTermCP() as it seems dangerous in portable code. Instead I'm adjusting DispCP and KeyCP separately
depending on above factors. KeyCP is only set on *nix systems.
Plus HB_GTI_CODEPAGE on win when ISO CP is used. I didn't
test UNICODE mode in this scenario yet.

For me this is a little confusing. Prone to break easily.

Brgds,
Viktor

CP UPPER¶

Re: [Harbour] UPPER error iwith some CP-s Uto 06 Okt 2009 18:58:57

From:     druzus@acn.waw.pl
To:     harbour@harbour-project.org
Reply To:     harbour@harbour-project.org
Sender:     harbour-bounces@harbour-project.org
On Tue, 06 Oct 2009, Bisz István wrote:

Hi,

> I found a quite strange behavior in  some CP settings necessary in my
> project.
> See the following sample:
> CODE
> proc main()
>    set alternate to uperr.txt additive
>    set alternate on
>    REQUEST HB_CODEPAGE_TR857
>    HB_SETCODEPAGE( "TR857" )
>    ? "diag=diag", UPPER("diag=diag")
>    ? "diag", UPPER("diag")
> return
> ENDCODE
> generating the wrong output:
> diag=diag DAG=DAG
> diag DIAG

It's Clipper compatible behavior in UPPER() optimization.
Clipper optimize UPPER( <cConst> ) at compile time if <cConst>
contains only characters like [A-Za-z0-9 ] and as result if
gives <cUpperConst> where characters like [a-z] are converted
to [A-Z]. During compilation CP is unknown so only such strings
are translated and only pure Latin letters.
In Harbour Clipper behavior is fully replicated because
some code which initialize static variables needs it, i.e.:
   static s := upper( "diag" )
Unfortunately it creates problems for Turkish CPs where upper("i")
is not "I" but due to compile time optimization it's wrongly
translated to "I".
In your example first string contains "=" character what disables
compile time UPPER() optimization so it's correctly translated at
runtime but the second string is fully optimized.
The only one solution I can give you is not using UPPER() with
string constant values containing Turkish strings. Maybe in the
future I'll add new -k? switch to disable UPPER() optimization
but I cannot make it in default builds due to compatibility with
existing code. If it's critical for you now then you can disable
UPPER() optimization in Harbour compiler code and recompile your
custom Harbour version.

best regards,
Przemek