using 'wait with your own port handler?
[1/4] from: d95-mjo::nada::kth::se at: 24-Jun-2001 21:24
Hi!
I read the following article earlier today:
> Writing your own Protocol Handler by Jeff Kreis.
> http://www.rebolforces.com/articles/protocols.html
and I thought it was very interesting. I tried to use this approach on a
little project I'm doing, but I'm no longer sure if I can get it to do
what I want it to do. This is what I'm trying to do:
Using View/Pro and a DLL, I've been able to play MP3 files by calling
functions in the DLL from REBOL. What I'd like to do is to create a
port interface for my MP3 routines that works like the sound://
port. It would look something like this:
;-- Open mp3 port (load DLL etc)
mp3-port: open mp3://
;-- Play mp3 file (by calling DLL function)
insert mp3-port %nameofsong.mp3
;-- Wait for mp3 to finish (somehow)
wait mp3-port
;-- Close mp3 port (free DLL etc)
close mp3-port
This all seems to work, EXCEPT for 'wait. So, my question is this: Is it
at all possible to write your own port handler that you can wait for using
'wait? If so, how would I do that? I've used the make root-protocol
approach and I can't really figure it out. I tried using 'wait on my
port, just to see what would happen, and it crashed REBOL. :-) The reason
I want to use 'wait is that I would like to be able to wait for other
ports at the same time. I have a feeling that 'wait is a bit too
tied to low level port internals to work with my higher level port
handler. Anyway, if anyone has any suggestions or ideas about how to make
this work (or why it won't work), I'd be very grateful if you'd like
to share this information on the mailing list. :-)
(I forgot to mention that I haven't really thought about exactly HOW to do
the actual wait-for-mp3 function, because first I'd need to understand how
to use 'wait on my own port, in general. At the moment, it seems like
I'd have to use some kind of poll loop.)
TIA,
Martin Johannesson
[d95-mjo--nada--kth--se]
[2/4] from: holger:rebol at: 25-Jun-2001 15:31
On Sun, Jun 24, 2001 at 09:24:51PM +0200, Martin Johannesson wrote:
> This all seems to work, EXCEPT for 'wait. So, my question is this: Is it
> at all possible to write your own port handler that you can wait for using
> 'wait?
The short answer is no. There are two issues:
- How do you get REBOL to "wake up" when your library is done
playing ? This is the difficult part and always OS-dependent. For Windows
there would, e.g., have to be a way for a script to allocate a WinMsg,
register it with REBOL's internal wait handler, and tie it to a port.
For other operating systems the procedure would be different. Not
supported at this time.
- How do you get 'wait to realize that your port is done ? This
will be possible in the next major Core release.
At the moment only two types of ports can have 'wait functionality: ports
with port handlers written in C, and ports which are directly based on ports
that have 'wait functionality. For instance you can 'wait for an http port
because it uses a tcp port that supports 'wait. Port handlers have a
function 'get-sub-port which is supposed to return the next-lower port.
The default behavior (used by http) is to return port/sub-port, i.e. for
http the tcp port is returned.
> If so, how would I do that? I've used the make root-protocol
> approach and I can't really figure it out. I tried using 'wait on my
> port, just to see what would happen, and it crashed REBOL. :-)
That should not happen...
--
Holger Kruse
[holger--rebol--com]
[3/4] from: petr:krenzelok:trz:cz at: 26-Jun-2001 7:01
Holger Kruse wrote:
> On Sun, Jun 24, 2001 at 09:24:51PM +0200, Martin Johannesson wrote:
> > This all seems to work, EXCEPT for 'wait. So, my question is this: Is it
<<quoted lines omitted: 4>>
> playing ? This is the difficult part and always OS-dependent. For Windows
> there would, e.g., have to be a way for a script to allocate a WinMsg,
and? :-) just kidding, see below ...
> register it with REBOL's internal wait handler, and tie it to a port.
> For other operating systems the procedure would be different.
So, I thought each platform has ability to somehow generate/send events/messages
.... probably difficult to wrap into one consistent solution?All that
multiplatform issues are strange things sometimes. Last time I was surprised
once Gabriele said my file locking mechanism will not work on Unix, as even if
app regularly locks it, another task can delete it ...
However, sometimes the value of certain solution is little too high to miss it
:-) Sometimes also, so called "multiplatform" usage is little bit blurred. The
answer is simple - the script does work for you or not. What is the difference
if my script will not work for me, because someone used odbc in it, while I
don't own /command? Or sound? I can't use it while I buy /Pro. I noticed that
even in current state of Rebol development, there are some slight differences
(Be and Elate don't supporting some network blabla I don't remember now, ability
to use some special Mac fs capability ...)
So, if some much desired functionality (e.g. ability to produce own events)
would be possible to be supported on 80 - 90% of platforms, it is worth
consideration imo.
btw: I noticed that few ppl already expressed desire to have even mechanism
available in Core. What for? I don't know :-) But having face/rate enables us to
have some kind of pseudo tasking, be more async, etc. Maybe we are looking for
some kind of
watch: make timer! 0.1 func-here
or
watch: open [
scheme: 'timer
rate: 1
awake: func-here
]
?
Or will we get regular threading? I remember you stated that it is not so easy
(if even possible) to make the feature work on other platforms? But in general,
having threading or not, View is very nice example of what can be achieved by
very clever design. I can't wait to see, what you guys at RT are cooking to
bring us even more asynchronicity :-)
-pekr-
[4/4] from: holger:rebol at: 26-Jun-2001 6:33
On Tue, Jun 26, 2001 at 07:01:32AM +0200, Petr Krenzelok wrote:
> So, I thought each platform has ability to somehow generate/send events/messages
No. Unix does not, for instance.
> (Be and Elate don't supporting some network blabla I don't remember now, ability
> to use some special Mac fs capability ...)
Yes, but there is a difference between having a generic mechanism (like sound
or multicasting) which simply is not supported by all operating systems, and
having a mechanism which is specifically tied to a single OS to start with.
> So, if some much desired functionality (e.g. ability to produce own events)
> would be possible to be supported on 80 - 90% of platforms, it is worth
> consideration imo.
Yes. It is a trade-off that will have to be looked at in each case.
> watch: make timer! 0.1 func-here
Yes. Real timers are a possibility.
> Or will we get regular threading?
Possibly, not soon though.
--
Holger Kruse
[holger--rebol--com]
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted