From jan@swi.psy.uva.nl Mon Jan  7 21:14:27 2002
Received: from gollem.swi.psy.uva.nl (root@gollem.swi.psy.uva.nl [145.18.152.30])
	by swi.psy.uva.nl (8.11.6/8.11.2) with ESMTP id g07KERT11520
	for <prolog@swi.psy.uva.nl>; Mon, 7 Jan 2002 21:14:27 +0100 (MET)
Received: (from jan@localhost)
	by gollem.swi.psy.uva.nl (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) id g07KERU01717
	for prolog@swi.psy.uva.nl; Mon, 7 Jan 2002 21:14:27 +0100
Date: Mon, 7 Jan 2002 21:14:27 +0100
Message-Id: <200201072014.g07KERU01717@gollem.swi.psy.uva.nl>
From: Jan Wielemaker <jan@swi.psy.uva.nl>
Subject: Re: [SWIPL] Two questions: multimedia timers and threads
To: prolog@swi.psy.uva.nl
Phone: +31 - 20 - 525 6121

> Does anybody have experience or would it be possible to use SWI/XPCE for 
> multi media application. I would like to make an composer tool which needs 
> to dispatch midi-events. The timer in xpce is not a multimedia timer. Of 
> course one way would be to copy the (xpce) timer code and make the 
> necessary adjustments to make it a multimedia timer, but I don't know if 
> this would be the proper way, since this is clearly not easily portable.
> (Some 5 years ago I made a prototype in SWI which used mmtimer-callbacks 
> form a dll, but the way timers are implemented in xpce are much better :) , 
> unfortunately they are not multi media timers :(

I'm not that much of a Windows person :-) Ideally functionality in XPCE
should be implemented in all versions of XPCE (which means based on
Win32 as well as Unix/X11).  Sometimes this is impossible or at least
not very practical.  One example is the Windows MetaFile, which
clearly provides useful functionality on Windows platforms without
anything similar for Unix/X11.  Contrary, parts of Unix/X11, especially
in process control are hard to emulate on Windows.  For Windows functionality
that is unlikely to have a portable counterpart the prefix win_ is used.

I don't know about multi-media timers.  In what way do they differ
from `normal' timers?  If they differ radically from normal timers one
might consider to introduce a class win_multi_medium_timer.
Alternatively, additional attributes for resolution, scheduling,
etc. attributes may be added to normal timer objects and the
implementation decides, based on these attributes, which system
primitives to use.  If feasible I'd opt for this solution.

Feel free to add what you need and contact me if you have trouble finding
out how to add classes or methods.

> What is the status of thread support in the windows version of SWI. How 
> difficult would it be to enable threads under windows or has anybody 
> experience in this matter. Or would it be easier to create multiple engines 
> from a  host language, like C?

This has been discussed to some extend before.  SWI-Prolog threads are
based on POSIX threads.  Implementation-details are only found on
pl-thread.[ch], that aren't very long nor complicated.  One option
would be to use the POSIX thread-emulation layer (pthread-win32?), but
considering the localised nature of the SWI-Prolog threading code,
redefining the primitives using the Win32 API looks like a better
solution.  There are two hard problems.  One is to write a replacement
for attaching an X11 xterm console to a thread, which ideally implies
generalising the current console code.  The other is handling
atom-garbage collection.  This is initiated as the N-th new atom is
created by a thread.  The initiating thread locks the atom-handling
routines, sets up a semaphore and uses pthread_kill() to ask all
threads to update the atom reference-counts.  There is nothing similar
to pthread_kill() under Windows (it's use is *very* tricky, but safe
for this case).  A possible Win32 alternative might be for the initialising
thread to stop the threads one-by-one and do the reference update itself:

foreach thread in current-threads
  stop thread
  mark-atoms for thread
  restart thread
done

Of course, if you have multiple processors this means one processor does
the entire job ...

[Most of the multi-threading code is exactly about allowing multiple
engines to co-exist in the same address-space]

	Cheers --- Jan

