Right, but is there a concurrent use of this semaphore?
I mean the active process will acquire AccessSema again and again until it
give up control.
A process of same priority cannot take control and concurrently preempt
AccessSema until then.
The active process will give up control if
1) it explicitely yield (not that many senders)
2) or if a higher priority process take possession of AccessSema.
  AccessSema is only used by endEntry, so it would mean a higher priority
proess is transcripting.
3) or if the acquisition of another semaphore is blocked...

I failed to find occurences of 1) and 2) so I was tempted by explanation 3)
but also failed to find it...
Case of blindness?

2015-01-07 19:33 GMT+01:00 Levente Uzonyi <leves at elte.hu>:

> Transcript >> #endEntry uses the AccessSema semaphore. That method is sent
> from #show:.
>
> Levente
>
>
> On Wed, 7 Jan 2015, Nicolas Cellier wrote:
>
>
>> ---------- Forwarded message ----------
>> From: Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>
>> Date: 2015-01-02 21:16 GMT+01:00
>> Subject: Process scheduling question
>> To: The general-purpose Squeak developers list <squeak-dev at lists.
>> squeakfoundation.org>
>>
>>
>> Interestingly, using Transcript in Processes in Squeak/Pharo make them
>> behave as if the scheduler was preemptive, which it is not.
>>
>> http://stackoverflow.com/questions/27731274/smalltalk-
>> visual-works-concurrency
>>
>> So there must be some sort of wait on a busy Semaphore, but where?
>> I failed to find it...
>>
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150107/ed567e63/attachment.htm