I would say it is "a" way to use a Semaphore and the idea that it is a
limit is the way that I've always understood it.

The fact that it's a gobal semaphore means that it controls access to the
code that follows and the scope of that is for all machines connected to
the server. The semaphore doesn't mean that other methods cannot run. That
is a function of "cooperative multitasking" and, now that we can run code
pre-emotively, developers will have to have a more clear understanding of
(and better control of) what runs, when.

I'm making a narrow distinction there but I think it's a valid one.

Douglas von Roeder

On Wed, Oct 25, 2017 at 9:15 AM, Arnaud de Montard via 4D_Tech <> wrote:

> > Le 25 oct. 2017 à 17:55, Douglas von Roeder via 4D_Tech <
>> a écrit :
> >
> > Arnaud:
> >
> > My understanding is that, given that 4D's scheduler has been "cooperative
> > multitasking" for virtually all of its history, the Idle command
> instructs
> > the current process to yield time to other processes. Without the
> While…End
> > while loop and the Idle command, the current process would hit the
> > Semaphore command and processing would stop until 300 ticks had passed.
> > That process would not yield CPU, causing all processing to stop.
> Yes, but when I look at examples in the Semaphore function, only the 1
> (the oldest?) uses while+idle. And I remember Olivier Deschanels saying
> during a training that the second parameter was made to limit the delay.
> Now, is it "a" way to delay, "the" way, when to mix both? That's what I'd
> like to know. And more specifically with a global semaphore, as in David's
> situation.
> --
> Arnaud de Montard
> **********************************************************************
> 4D Internet Users Group (4D iNUG)
> FAQ:
> Archive:
> Options:
> Unsub:
> **********************************************************************
4D Internet Users Group (4D iNUG)

Reply via email to