#steps on things
10 messages in this thread
I'm using the timer device, and I'm having some problems with it. I
downloaded the source code in the C data library ( a loooong time ago)
written by Rich Roberts that details how to use the timer.device. The ROM
kernal manual is less than helpful, the example seems to be broken in
there.
The source code, as written by mr Rodgers, does _exactly_ what it is
advertised to, except it steps on low memory. I can't see why it should,
either. It's really bizzarre, as the thing _works_ exactly as you would
expect it to. This is the cause of a bug within CoCommm, and I want to
squash the darn thing!
The upshot of this is, if anyone out there has extensive experience with
both the timer.device and messageports, I'd like to give you a call and
discess this with you. My nickle, of course.
I'm no expert… and you probably are already aware of this but….
there _is_ a bug in the timer.device when you use '0' or very low numbers
(1,2,3,etc) for your timeout value (I _think_ this refers to the 'ticks'
field… 1 second should be fine). Again, this may not apply to your
problem but I thought I'd throw it out… – Keith
Appreciate it, Keith – I think I _may_ have found it. The code that I was
referring to setup it's own message port. This involved allocating a
signal. The timer close routine did a RemPort and a CloseDevice (in
opposite order) but did not do an Explicit "FreeSignal(signum)". It looked
to _me_ like it was missing; and I noted that the code didn't check to see
if it had really gotten the signal, either – so I changed it to tell me if
it couldn't _get_ a signal, and then I also changed the timer close so that
the signal was freed.
It's not telling me it can't gett signals, and it's not stomping on things
anymore, either, at least at this point. I have memwatch running, and so
far, so good. I've tried the things that dependably caused it, and they no
longer do. I have one more thing to go, that's the download code – it used
the same timer code, and stomping occured then, too. Hopefully, that was
it. Later I plan to remove the free signal call and leave the screams about
"I can't get no signal" in there, and see if it pukes – hopefully, it will,
and I can relax. Gadz, I hate bugz! This has been a bad one, too – it
wasn't my code that caused it, and it didn't show up when it happened, so
it was _horrible_ to find. –Ben–
No, for sure I found it. It was the Allocsignal without the FreeSignal in
the port clean up. Darwin knows CoComm has enough signal bits running
around anyway, I can't afford to go throwing them out the proveribal
portal.
I figure, one for serial port, one for each console, one for gadget window,
one for regular key compare timer, one for general purpose timer, one for
review buffer (if it's open), one for auxillary window (file requester,
locator, keydefs, palette, sen list, gadget editing window, prefs window)
Those don't multitask like the others, so there's only 1 signal used for
whichever (if any) of that group is open, but still. <grin>.
The compare operation in the function keys was using the timer to limit
that amount of time it would wait to see if the text was ever going to
come… in my sign in sequence, I use it about 4 times… that's 4 more
signal bits! <Gadz!> Pretty soon, you run out of signal bits (frankly, I
don't think there are enough available, in general – this is sort of up
against the wall now, as far as I'm concerned) and you have the nasty
feature.
Incidentally, chekc this out:
I do the allocsignal, and if it returns (-1) I pop up a requester that says
"you don't have a signal bit" and etc. Guess what? According to Tobbes
memwatch, low memory gets stepped on right then, no waiting thank you very
much. I wonder if the requester (using autorequest here, folks) tries to
allocate a signal bit and doesn't check it? Because the trampling occurs
before the autorequest window is fully rendered…. makes you wonder if
it's the autorequest getting ill, or if AllocSignal goes nutz because it
didn't have a signal to give you.
Life is so interesting programming this machine. <glazed look>
If you ever do get that figured out, I'd be _very_ interested in the
general methods you're using. I've added some timeout code to…ummm a
certain program and the Guru has been merrily chasing me ever since. It
doesn't strike until cleanup, and MemWatch does say something funny is
going on whenever a certain routine starts a timer (or so I suspect) Since
I've been depending on the system routines, and paying little heed to
signal allocation, perhaps this bug you've discovered is the cause of much
headscratching here.
Did you ever think of _sharing_ some of the signal bits???? Or maybe
sending messages to a common port instead of gobbling up all those
'limited resources'?? CoComm must multi-task rather poorly if _you_ have
all the signals allocated!
Nope. And CoComm multitasks just fine, Vic. Remember, those signal bits are
limited to 16 for a single task – not 16 for the machine. Once you click on
CoComm, it gets 16 it can use…. and I use a fair number of them. I even
have some to spare. But I can't afford for the spares (4 or 5) to be eaten
and never returned by CoComm itself, which is what was happening.
You know, things are _much_ easier to manage when each window gets it's own
IDCMP port. Likewise, the consoles. That's why CoComm uses alla them ports,
and that's why it's so powerful, too – because the resources that I have
are extremely easy to manage. You bring up something that's been bothering
me, though – why 16 signal bits? Seems to be pretty darn shortsighted to
me! I think that if you start something from a CLI as a task (either with
run or if it forks itself via cback.o or whatever) then the CLI is sitting
there with sigbits-forked sigbits available. Seems awfully stupid – that
limits the number of tasks you can have in a CLI – something I thought
wasn't supposed to happen. If it doesn't work that way, then I suppose
it's not so bad. I did see a comment to the effect that it did work that
way just recently, tho.
Why not 32 signal bits? I could use em. <grin> –Ben–
Ben, I think the other 16 (for a total of 32) are used for 'system wide'
thingies you can look at (I'll have to check my docs one more time). BTW, I'd
forgotten <hanging head in shame> that _each_ task got 16 signals.
Thass all right Vic. <Patting head>
Sure do wish I had more sigz for my own use, tho. I could use about 256 of em.
–Ben–