Re: Question about a test : gl_in_pthread.cpp

[Mehdi Sabwat]

Thanks Alon for the super clear explanation! Cheers

On Wed, Aug 28, 2019, 20:35 Alon Zakai  wrote:

> Thanks, I see now - the test is indeed marked as disabled in chrome, due
> to https://crbug.com/961765 which is why the failure wasn't noticed on CI.
>
> That test does pass with offscreen framebuffer + PROXY_TO_PTHREAD, as you
> said. That avoids using the native OffscreenCanvas support in the browser
> of canvas proxying, and does the proxying manually. In general that is less
> optimal, so it's not recommended.
>
> But here proxying the OffscreenCanvas hits a bug, related to adding
> PROXY_TO_PTHREAD to that test (as you did, and which works around the sync
> issue that the test is disabled because of), I filed
> https://github.com/emscripten-core/emscripten/issues/9344
>
> In general: OffscreenCanvas is the future in this area. But offscreen
> framebuffer can help in the meantime in browsers that don't support it yet.
>
> - Alon
>
>
> On Wed, Aug 28, 2019 at 5:10 AM Mehdi Sabwat 
> wrote:
>
>> Yes my command works but it's not the one that actually shows in
>> test_browser.py. And yes, I have Chromium 76.
>>
>> should it be changed?
>>
>> I wanted to know if the command that passes the test seems correct?
>>
>>
>> On Tuesday, August 27, 2019 at 10:28:32 PM UTC+2, Alon Zakai wrote:
>>>
>>> Oh sorry, looks like I confused test_webgl_offscreen_canvas_in_pthread
>>> with test_webgl_offscreen_canvas_in_proxied_pthread...
>>>
>>> Running your command on that test does work for me, on Chrome 76. Which
>>> version did you test on?
>>>
>>> On Tue, Aug 27, 2019 at 4:56 AM Mehdi Sabwat  wrote:
>>>
 Thank you for the details, the PR is not about the test I sent thought.

 To answer your question, in Chromium the test makes the page hang. I
 cannot get anything on the console unfortunately.

 If I add -s PROXY_TO_PTHREAD=1 (without OFFSCREEN_FRAMEBUFFER as stated
 in the test) I get :
 pthread_create: failed to transfer control of canvas "canvas" to
 OffscreenCanvas! Error: ReferenceError: document is not defined

 for gl_in_pthread.cpp:

 - if I don't use -s PROXY_TO_PTHREAD=1, the page hangs
 - if I don't use -s OFFSCREEN_FRAMEBUFFER=1 I get the error above

 On Tuesday, August 27, 2019 at 1:02:34 AM UTC+2, Alon Zakai wrote:
>
> I just refactored that test a little in
>
> https://github.com/emscripten-core/emscripten/pull/9293
>
> The flags used in the test now in test_browser.py should only be
> actually necessary ones.
>
> You do need either OffscreenCanvas support, or OFFSCREEN_FRAMEBUFFER.
> OffscreenCanvas is a browser API, which works in at least Chrome, while
> OFFSCREEN_FRAMEBUFFER compiles in some code to proxy GL commands to the
> main thread, so it's like a polyfill for OffscreenCanvas.
>
> Note that you currently need to set OFFSCREENCANVAS_SUPPORT even if
> using FRAMEBUFFER. I'm not sure why that is, but I think it's why your
> command didn't work. If that's not it, is an error shown in the dev 
> console
> perhaps?
>
>
> On Mon, Aug 26, 2019 at 9:52 AM Mehdi Sabwat 
> wrote:
>
>> Hi,
>>
>> The test
>> 
>> with these command options
>> 
>> fails in Chromium (page hanging after first pthread_create).
>>
>> em++ gl.cpp -o test.html -s USE_PTHREADS=1 -s PROXY_TO_PTHREAD=1 -s
>> PTHREAD_POOL_SIZE=2 -s -s OFFSCREEN_FRAMEBUFFER=1 -lGL -s
>> DISABLE_DEPRECATED_FIND_EVENT_TARGET_BEHAVIOR=1 --emrun
>>
>> I tried this instead and it seems to work better, is this the new way
>> to do `-s OFFSCREENCANVAS_SUPPORT=1` ? Should this be applied to all
>> gl/pthread tests?
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "emscripten-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to emscripten-discuss+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/emscripten-discuss/06462979-cf0b-4bd8-912d-1957f5d6b1ad%40googlegroups.com
>> 
>> .
>>
> --
 You received this message because you are subscribed to the Google
 Groups "emscripten-discuss" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to emscripten-discuss+unsubscr...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/emscripten-discuss/f58a7e32-fe5a-41eb-bf3e-a694354d785c%40googlegroups.com
 

Re: Question about a test : gl_in_pthread.cpp

[Alon Zakai]

Thanks, I see now - the test is indeed marked as disabled in chrome, due to
https://crbug.com/961765 which is why the failure wasn't noticed on CI.

That test does pass with offscreen framebuffer + PROXY_TO_PTHREAD, as you
said. That avoids using the native OffscreenCanvas support in the browser
of canvas proxying, and does the proxying manually. In general that is less
optimal, so it's not recommended.

But here proxying the OffscreenCanvas hits a bug, related to adding
PROXY_TO_PTHREAD to that test (as you did, and which works around the sync
issue that the test is disabled because of), I filed
https://github.com/emscripten-core/emscripten/issues/9344

In general: OffscreenCanvas is the future in this area. But offscreen
framebuffer can help in the meantime in browsers that don't support it yet.

- Alon


On Wed, Aug 28, 2019 at 5:10 AM Mehdi Sabwat  wrote:

> Yes my command works but it's not the one that actually shows in
> test_browser.py. And yes, I have Chromium 76.
>
> should it be changed?
>
> I wanted to know if the command that passes the test seems correct?
>
>
> On Tuesday, August 27, 2019 at 10:28:32 PM UTC+2, Alon Zakai wrote:
>>
>> Oh sorry, looks like I confused test_webgl_offscreen_canvas_in_pthread
>> with test_webgl_offscreen_canvas_in_proxied_pthread...
>>
>> Running your command on that test does work for me, on Chrome 76. Which
>> version did you test on?
>>
>> On Tue, Aug 27, 2019 at 4:56 AM Mehdi Sabwat  wrote:
>>
>>> Thank you for the details, the PR is not about the test I sent thought.
>>>
>>> To answer your question, in Chromium the test makes the page hang. I
>>> cannot get anything on the console unfortunately.
>>>
>>> If I add -s PROXY_TO_PTHREAD=1 (without OFFSCREEN_FRAMEBUFFER as stated
>>> in the test) I get :
>>> pthread_create: failed to transfer control of canvas "canvas" to
>>> OffscreenCanvas! Error: ReferenceError: document is not defined
>>>
>>> for gl_in_pthread.cpp:
>>>
>>> - if I don't use -s PROXY_TO_PTHREAD=1, the page hangs
>>> - if I don't use -s OFFSCREEN_FRAMEBUFFER=1 I get the error above
>>>
>>> On Tuesday, August 27, 2019 at 1:02:34 AM UTC+2, Alon Zakai wrote:

 I just refactored that test a little in

 https://github.com/emscripten-core/emscripten/pull/9293

 The flags used in the test now in test_browser.py should only be
 actually necessary ones.

 You do need either OffscreenCanvas support, or OFFSCREEN_FRAMEBUFFER.
 OffscreenCanvas is a browser API, which works in at least Chrome, while
 OFFSCREEN_FRAMEBUFFER compiles in some code to proxy GL commands to the
 main thread, so it's like a polyfill for OffscreenCanvas.

 Note that you currently need to set OFFSCREENCANVAS_SUPPORT even if
 using FRAMEBUFFER. I'm not sure why that is, but I think it's why your
 command didn't work. If that's not it, is an error shown in the dev console
 perhaps?


 On Mon, Aug 26, 2019 at 9:52 AM Mehdi Sabwat 
 wrote:

> Hi,
>
> The test
> 
> with these command options
> 
> fails in Chromium (page hanging after first pthread_create).
>
> em++ gl.cpp -o test.html -s USE_PTHREADS=1 -s PROXY_TO_PTHREAD=1 -s
> PTHREAD_POOL_SIZE=2 -s -s OFFSCREEN_FRAMEBUFFER=1 -lGL -s
> DISABLE_DEPRECATED_FIND_EVENT_TARGET_BEHAVIOR=1 --emrun
>
> I tried this instead and it seems to work better, is this the new way
> to do `-s OFFSCREENCANVAS_SUPPORT=1` ? Should this be applied to all
> gl/pthread tests?
>
> --
> You received this message because you are subscribed to the Google
> Groups "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/06462979-cf0b-4bd8-912d-1957f5d6b1ad%40googlegroups.com
> 
> .
>
 --
>>> You received this message because you are subscribed to the Google
>>> Groups "emscripten-discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to emscripten-discuss+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/emscripten-discuss/f58a7e32-fe5a-41eb-bf3e-a694354d785c%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> 

Caching POST responses in IndexedDB (bug?) + reading from indexeddb cannot be disabled

[Benjamin Golinvaux]

Hello

First post here. Hello everyone :)

I noticed two weird things and I'd like to check I am not dreaming.

*First, a minor issue *: I tried to use the following flags when performing 
an http request : EMSCRIPTEN_FETCH_LOAD_TO_MEMORY 
| EMSCRIPTEN_FETCH_PERSIST_FILE.
Then, later, I reverted to using only EMSCRIPTEN_FETCH_LOAD_TO_MEMORY.
I noticed that the emscripten fetch code always looks up the entry in the 
IndexedDB first, even with only the EMSCRIPTEN_FETCH_LOAD_TO_MEMORY flag 
specified. In that particular case, the existing entries in IndexedDB from 
my previous attempt were interfering with my requests (since I am quite new 
to web development -- I am now in it thanks to emscripten :) -- I did not 
know about the whole IndexedDB stuff and wasted some time trying to 
understand that). Don't you think that, by default, IndexedDB should not be 
used at all ?

*The real problem I have encountered *: I was performing a REST API call on 
some server (Orthanc) with a POST request. The responses were returned from 
the existing IndexedDB entries and, furthermore, it seems that *only part 
of the body is used in the index* : hundreds of calls to this endpoint, 
with different bodies, were always returning the responses of the first 
request.

My first question : shouldn't it be better to use the same rules to store 
the response in IndexedDB that the browser uses ? (POST not cached by 
default unless some header is added) ?
My second question (the important one) : is this possible that two POST 
requests with same URI but different bodies (only different after 30 
characters or something) return the same stored response ?

Thanks a lot in advance for your help sorting this out.

Best,

Benjamin Golinvaux
(Belgium)

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/6a44f3ff-bc39-415b-ac53-e92ebe0edbb2%40googlegroups.com.

Re: Future of (a)synchronous

[Beuc]

Hi,

On 26/08/2019 22:09, Alon Zakai wrote:
> On Sun, Aug 25, 2019 at 2:21 PM Beuc  > wrote:
>
> > Is there some use case you have that asyncify doesn't handle?
>
> I had answered you in the link above :)
>
> - debug capacity: Emterpreter provides a detailed stack trace whenever
>   trying to pause in the wrong place, which is a must-have to populate
>   the WHITELIST in complex code with indirect calls (e.g. Python);
>   here AFAICT the ASYNCIFY'd application will just skip the
>   emscripten_sleep() and crash mysteriously later.
>
> - pattern-matching in WHITELIST
>   (which I had implemented for Emterpreter)
>
>
> Would be good to get issues filed for those things if there aren't
> already. (I can try to find time to get to them myself, but not sure
> when I will be able to.)

I will when I can test asyncify on my production code. I hit several
issues with -upstream that are currently being resolved.

Cheers!
Beuc

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/966f0c50-e3c4-e6f0-10f1-fec35a055f68%40beuc.net.

Re: Question about a test : gl_in_pthread.cpp

[Mehdi Sabwat]

Yes my command works but it's not the one that actually shows in 
test_browser.py. And yes, I have Chromium 76.

should it be changed?

I wanted to know if the command that passes the test seems correct?


On Tuesday, August 27, 2019 at 10:28:32 PM UTC+2, Alon Zakai wrote:
>
> Oh sorry, looks like I confused test_webgl_offscreen_canvas_in_pthread 
> with test_webgl_offscreen_canvas_in_proxied_pthread...
>
> Running your command on that test does work for me, on Chrome 76. Which 
> version did you test on?
>
> On Tue, Aug 27, 2019 at 4:56 AM Mehdi Sabwat  > wrote:
>
>> Thank you for the details, the PR is not about the test I sent thought.
>>
>> To answer your question, in Chromium the test makes the page hang. I 
>> cannot get anything on the console unfortunately.
>>
>> If I add -s PROXY_TO_PTHREAD=1 (without OFFSCREEN_FRAMEBUFFER as stated 
>> in the test) I get :
>> pthread_create: failed to transfer control of canvas "canvas" to 
>> OffscreenCanvas! Error: ReferenceError: document is not defined
>>
>> for gl_in_pthread.cpp:
>>
>> - if I don't use -s PROXY_TO_PTHREAD=1, the page hangs
>> - if I don't use -s OFFSCREEN_FRAMEBUFFER=1 I get the error above
>>
>> On Tuesday, August 27, 2019 at 1:02:34 AM UTC+2, Alon Zakai wrote:
>>>
>>> I just refactored that test a little in
>>>
>>> https://github.com/emscripten-core/emscripten/pull/9293
>>>
>>> The flags used in the test now in test_browser.py should only be 
>>> actually necessary ones.
>>>
>>> You do need either OffscreenCanvas support, or OFFSCREEN_FRAMEBUFFER. 
>>> OffscreenCanvas is a browser API, which works in at least Chrome, while 
>>> OFFSCREEN_FRAMEBUFFER compiles in some code to proxy GL commands to the 
>>> main thread, so it's like a polyfill for OffscreenCanvas.
>>>
>>> Note that you currently need to set OFFSCREENCANVAS_SUPPORT even if 
>>> using FRAMEBUFFER. I'm not sure why that is, but I think it's why your 
>>> command didn't work. If that's not it, is an error shown in the dev console 
>>> perhaps?
>>>
>>>
>>> On Mon, Aug 26, 2019 at 9:52 AM Mehdi Sabwat  wrote:
>>>
 Hi, 

 The test 
 
  
 with these command options 
 
  
 fails in Chromium (page hanging after first pthread_create).

 em++ gl.cpp -o test.html -s USE_PTHREADS=1 -s PROXY_TO_PTHREAD=1 -s 
 PTHREAD_POOL_SIZE=2 -s -s OFFSCREEN_FRAMEBUFFER=1 -lGL -s 
 DISABLE_DEPRECATED_FIND_EVENT_TARGET_BEHAVIOR=1 --emrun

 I tried this instead and it seems to work better, is this the new way 
 to do `-s OFFSCREENCANVAS_SUPPORT=1` ? Should this be applied to all 
 gl/pthread tests?

 -- 
 You received this message because you are subscribed to the Google 
 Groups "emscripten-discuss" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to emscripten-discuss+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/emscripten-discuss/06462979-cf0b-4bd8-912d-1957f5d6b1ad%40googlegroups.com
  
 
 .

>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "emscripten-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to emscripten-discuss+unsubscr...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/emscripten-discuss/f58a7e32-fe5a-41eb-bf3e-a694354d785c%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/94e98298-fe60-4b39-844d-22b8ba306764%40googlegroups.com.

Smart pointer lifetime

[Shachar Langbeheim]

Hi,
The Embind page states "To manage object lifetime with smart pointers,
*embind* must be told about the smart pointer type", but I've created an
object using a smart pointer constructor and once the JS object is removed,
the object's destructor wasn't called.

This isn't surprising considering the prior statement "[...] there is no
way for Emscripten to automatically call the destructors on C++ objects.",
so it makes sense that Emscripten cannot call the smart pointer destructor.
But, if smart pointers destructors aren't called, but the pointers' share
count is incremented during their construction, the shared_ptr will never
release its contained object. That is, while I could add a custom deleter
for a raw pointer, I couldn't do that for a smart pointer.

Which statement is true? Do smart pointers manage the lifetime of the
internal objects, or they don't?

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CA%2B_KjGb1aLbEV_2uhxoUTW-y58Cfayou%3DWGDYPVfedjBPyiXOA%40mail.gmail.com.