Prev: Tcl 8.6 & IncrTcl...
Next: stretching sounds with snack ?
From: Roger O on 29 Oct 2009 04:44
On Oct 28, 10:06 pm, David Gravereaux <davyg...(a)pobox.com> wrote:

> Maybe the whole dance should be a new extended set of procedure for Tcl
> itself?  For example, You can skip Tcl_AsyncMark altogether if the core
> was compiled for thread support and use Tcl_QueueThreadEvent directly
> and being compiled in, it could know this.  That's one less thread-safe
> linkedlist in use.

Is there a description of this thread capability in Tcl, especially
from the C API? I have been using Tcl/Tk in a C app that has both
threads and async call backs that want to fiddle with the Tcl/Tk
parts. I have managed to keep things rather sane, despite a few
kludges.

What I would like is one interpreter (meaning one interpreter that
controls the GUI, which is what the Tcl/Tk stuff is mainly doing) that
can be approached from various threads and async callbacks. I have
this at present, but not using any of the Tcl C API thread components.
Perhaps part of my life could be easier if I use this?

I have stayed away from threaded Tcl as I felt there was too little in
the way of documentation, especially of the C API, to make my efforts
meaningful. Perhaps some docs do exist, and I have been remiss in my
education.

--
Roger Oberholtzer
From: David Gravereaux on 29 Oct 2009 04:59
Donal K. Fellows wrote:
...
> There has been fighting over that API (the AsyncProc stuff) as to what
> it actually means between those who use it for dealing with Unix
> signals and those who use it for munging stuff with threads.

Tcl_AsyncMark works great for us threading folks as a way to get into
Tcl from the outside whether Tcl was compiled for thread-support or not.

I like it very much. Like Ashok, I use it exclusively for a foreign
thread entry to push stuff into the event loop and Tcl_Obj creation
prior to the event being queued. Although Tcl_QueueThreadEvent exists
when the core is compiled for thread support, there's no guarantee all
cores (when an application is dynamically loading tcl) will have that.
To me, Tcl_AsyncMark provided the perfect mechanism to get inside.

Yes, rather different than event sources, as this is a feed-forward
method rather than group polling.

Since Tcl_[Save|Restore]InterpState() arrived I have yet to see just how
safe it is to eval code in an asyncProc, but would be worth a test case
from within an asyncProc.

Conceptually, I'm not really against eval'ing code within an asyncProc.
I'm conceptually against having to use a fine grained interrupt to do
it. Everyone else uses the event loop. That's the proper place to run
normal priority work.

--


From: Donal K. Fellows on 29 Oct 2009 09:26
On 29 Oct, 08:59, David Gravereaux <davyg...(a)pobox.com> wrote:
> Tcl_AsyncMark works great for us threading folks as a way to get into
> Tcl from the outside whether Tcl was compiled for thread-support or not.

Well there's several use cases, not all of which are thread-related.
I'm just trying to fill out (an approximation of) the whole history...

> I like it very much.  Like Ashok, I use it exclusively for a foreign
> thread entry to push stuff into the event loop and Tcl_Obj creation
> prior to the event being queued.

We do not advise allocating a Tcl_Obj from any thread that Tcl doesn't
know about or passing an object from one thread to another. This is
because we do not like to guarantee that we will not use lock-free per-
thread object pooling (good for performance, bad for nasty inter-
thread tricks).

> Conceptually, I'm not really against eval'ing code within an asyncProc.
> I'm conceptually against having to use a fine grained interrupt to do
> it.  Everyone else uses the event loop.  That's the proper place to run
> normal priority work.

Evaluating code in an asyncProc is supposed to work; it's a clear use
case of very long standing. But if it's not an interrupt, queue it
anyway. (In fact, on Unix I'd advise queueing some interrupts too;
SIGWINCH for example...)

Donal.
From: David Gravereaux on 29 Oct 2009 12:20
Roger,

I wrote some stuff a long time ago about this
Tcl_AsyncMark/Tcl_QueueEvent method about 10 years ago during the early
Tcl 8.4 days:
http://sourceforge.net/projects/tomasoft/files/TES/1.4/tes-1.4.zip/download

--


From: David Gravereaux on 29 Oct 2009 13:22
Donal K. Fellows wrote:
> On 29 Oct, 08:59, David Gravereaux <davyg...(a)pobox.com> wrote:
>> Tcl_AsyncMark works great for us threading folks as a way to get into
>> Tcl from the outside whether Tcl was compiled for thread-support or not.
>
> Well there's several use cases, not all of which are thread-related.
> I'm just trying to fill out (an approximation of) the whole history...
>
>> I like it very much. Like Ashok, I use it exclusively for a foreign
>> thread entry to push stuff into the event loop and Tcl_Obj creation
>> prior to the event being queued.
>
> We do not advise allocating a Tcl_Obj from any thread that Tcl doesn't
> know about or passing an object from one thread to another. This is
> because we do not like to guarantee that we will not use lock-free per-
> thread object pooling (good for performance, bad for nasty inter-
> thread tricks).

Of course, that's why I do it in the asyncProc as described.

>> Conceptually, I'm not really against eval'ing code within an asyncProc.
>> I'm conceptually against having to use a fine grained interrupt to do
>> it. Everyone else uses the event loop. That's the proper place to run
>> normal priority work.
>
> Evaluating code in an asyncProc is supposed to work; it's a clear use
> case of very long standing. But if it's not an interrupt, queue it
> anyway. (In fact, on Unix I'd advise queueing some interrupts too;
> SIGWINCH for example...)
>
> Donal.


--


First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Tcl 8.6 & IncrTcl...
Next: stretching sounds with snack ?